►
From YouTube: Kubernetes SIG Multicluster 20180327
Description
See this page for more information: https://github.com/kubernetes/community/blob/master/sig-multicluster/README.md
A
B
C
Right,
so
can
you
all
hear
me
sure
so
I
was
asked
to
come
here
and
talk
a
little
bit
about
helm,
3
and
particularly
because
how
you
deploy
packaged
applications
affects
multi
cluster
and
we're
going
from
a
helm
to
Worlds
with
tiller
and
lots
of
things
to
a
helm.
3
is
a
major
breaking
change
from
Helton
to
I'll,
just
dig
in
to
kind
of
what
we've
got
a
helm.
3
kicked
off
at
the
helm
summit
back
in
February
and
since
then,
we've
been
working
mostly
on
clarifying
our
directions.
C
C
C
We
wanted
to
make
sure
we
are
heading
in
the
right
direction
to
meet
the
needs
of
who
our
audience
was
because
when
we
started
talking
about
stuff,
the
audience
was
all
over
the
place
and
people
had
all
of
these
desires
and
helm
is
not
trying
to
solve.
All
of
you
know
everybody's
problems,
it's
trying
to
focus
on
a
specific
set
and
then
kind
of
had
clear
interfaces.
So
people
who
want
to
focus
on
the
other
problems
know
how
home
can
fit
into
that
picture,
and
so
one
of
the
first
things
we
did
was.
C
We
actually
worked
on
a
set
of
user
profiles
that
identified
the
profiles
in
scope,
an
otoscope,
the
in
scope
is,
you
know
the
application
operator,
and
these
are.
These-
are
profiles
describing
roles?
The
same
person
may
end
up
fulfilling
more
than
one
of
those
roles
and
some
companies
and
in
other
companies
it
may
be
different
right,
so
we
have
an
application
operator
who's
actually
going
to
operate
an
application,
the
application
distributor.
This
is
the
person
who
might
package
up
a
chart
and
distribute
it,
and
one
of
the
things
that
I,
like
is
data
dogs.
C
You
get
application
of
this.
They
have
stuff
that
agent
that
are
running
cluster,
that
actually
phones
home
to
their
software
as
a
service,
but
they're,
not
the
main
users
of
it
who
are
going
to
consume
and
operate
the
application.
Lots
of
people
in
different
companies
are
in
different
organizations,
and
so
data
dog
will
package
up
what
they
need
to
run
in
a
cluster
in
a
community
chart
and
then
distribute
that
for
others
to
use.
C
There
were
a
lot
of
conversations
that
happen
at
the
summit
and
afterward
to
kind
of
get
into
this.
This
gives
an
overview
and
the
user
stories
are
actually
at
the
end.
We've
been
collecting
user
stories
from
different
places
from
nodes
from
summit
conversations
from
interviewing
people
at
companies,
because
we've
been
going
around
to
some
of
the
the
major
home
users
and
just
asking:
how
do
you
use
it?
What
do
you
need?
C
What
are
your
interactions
like,
and
so
we've
come
to
is
a
helm,
three
design
proposal
that
was
shared
last
Thursday
and
we'll
be
continuing
to
talk
on
it
and
once
we're
in
good
shape.
That's
when
everything
will
get
going,
but
the
top
level
summary
is
first
tiller
is
gone
for
those
of
you
who
don't
know
there
is
helm
the
client
side
until
the
server
side
that
continues
to
live
on,
and
in
this
case
tiller
is
going
to
go
away
completely
and
helm
will
be
a
client-side
piece
of
functionality.
C
C
A
C
All
right
helm,
one
had
no
tiller
component.
It
was
when
how
merged
with
deployment
manager
that
a
server
side
component
was
added,
and
so
it's
it
appears
to
be
going
away
again,
because
a
lot
of
people
have
been
trying
to
work
around
it,
and
there
are
things
such
as
our
back,
because,
if
you
have
tiller
tiller
has
to
now
have
a
you
know,
a
user
or
interaction
in
order
to
do
those
things.
So
how
does
our
back
work
in
that
world?
If
you
remove
tiller
and
the
home
client?
B
C
B
So
what
I
meant
by
our
back?
So
so
if
there
was
a
good
solution
to
that,
where,
where
the
complications
are
service,
accounts
etc
resolved,
would
you
prefer
to
run?
The
stymie
seems
like
there
are
a
million
benefits
to
doing
it.
Server-Side
I'm
just
wondering
whether
there
reasons
other
than
permissions
and
authentication
related
problems
that
you
moved
back
to
a
client-side
model.
C
C
There's
projects
such
as
tiller,
local
or
people
who've
built
our
own
tools
that
wrap
tiller,
so
they
can
get
the
outputs
out
of
it
and
then
do
something
else
with
them,
and
so
it
turns
out
that
there's
a
lot
of
reasons
not
to
have
a
server-side
tiller
or
to
interact
with
more
native
things
within
the
kubernetes
eco
stride,
to
do
things
more
natively
and
move
it
more.
Client-Side
works
for
a
lot
more
use
cases
and
it
removes
some
of
the
problems
we
have
today.
C
C
C
Charts
are
updated
with
libraries,
schematized
values
and
an
extension
directory.
I'll
talk
more
about
that
in
a
minute.
Libraries
allow
us
to
have
library
charts,
because
not
everybody
there's
a
lot
of,
don't
repeat
yourself,
and
so
we
want
to
be
able
to
have
libraries
that
allow
you
to
do
those
kinds
of
things.
Schema
ties,
values.
If
you
deal
with
the
values
file
now
you
don't
necessarily
know
what
everything
means
or
descriptions.
You
can't
automatically
generate
UIs
and
that's
a
problem,
so
schematized
values
would
be
a
JSON
schema
file
that
could
accompany
the
values
file.
C
To
tell
you
what
stuff
meant
and
then
extensions
and
I'll
get
more
into
that
in
a
minute.
We're
also
going
to
do
a
lifecycle
events,
emitter
handler
model
around
it
and
that'll
get
into
things
like
how
extensions
can
grab
a
hold
of
events
and
then
act
on
them
within
a
chart.
It's
basically.
This
is
an
extension
to
what
you
can
do
with
charts.
Today
there
will
be
an
embedded
Lua
engine
for
scripting
the
event
handlers.
There
was
an
analysis
done
to
say
what
should
we
use
and
why
should
we
use
it?
Java
Script
Lua
different.
C
You
know
different
possibilities
and
we
looked
at
libraries
and
go
that
you
could
use.
You
know
we
got
a
cross
compile
for
different
languages
and
how
do
we
distribute
that?
And
it
turns
out
that
Lua
worked
the
best
in
the
analysis.
So
there's
an
embedded
lewin
engine
to
deal
with
that
state
is
maintained
with
a
CR
D,
which
is
the
release
c
rd
and
a
release
version
secret,
or
they
might
actually
both
be
secrets.
C
Now
we're
looking
at
the
best
way
to
handle
it
and
they've
gone
back
and
forth
between
c
RDS
and
secrets
and
some
different
things,
but
we're
trying
to
keep
it
with
a
release
and
a
release.
Version
object,
resources
in
home
that
were
created
by
hooks,
which
were
part
of
the
event
lifecycle,
we're
not
tracked
before
you
had
to
manually
clean
up
for
those
things.
C
C
One
of
the
things
that's
long
been
asked
for
is
to
have
a
pull
based
where
you
have
a
service
running
in
the
cluster,
that
monitors
for
a
change
in
chart
set
and
then
pulls
those
charts
in
and
deploys
those
it's
a
pull
based
model
rather
than
the
event
pushed
based
model.
And
so
one
of
the
other
projects
that
we're
gonna
look
at
doing
is
takes
that
same
package
and
creates
a
server-side
service
that
can
be
using
a
pull
based
model.
C
It
receives
events,
pulls
down,
chart
updates
and
then
deploys
them
into
the
cluster,
and
this
one
is
actually
kind
of
interesting
for
the
multi
cluster,
because
you
could
deploy
chart
updates
to
your
chart,
repository
in
one
location,
and
you
could
have
a
helm
controller
running
in
more
than
one
cluster,
and
it
could
observe
that
a
new
version
came
out,
pull
those
down
and
deploy
them
within
the
cluster
automatically.
This
kind
of
is
more
of
the
chef
based
model
if
you're
familiar
with
it.
C
C
No,
okay
and
cross-platform
plugins
in
Lua,
since
we're
already
gonna,
have
the
embedded
engine
we've
looked
at
exposing
that,
because
home
is
a
pluggable
system
that
where
plugins
can
respond
to
things
like
events
in
the
lifecycle
like
home
right
now
has
downloaders
and
those
downloaders
can
be
pluggable
based
on
your
URL
scheme,
so
I
can
have
s3
colon
slash,
slash
and
a
plugin
will
have
registered
to
fetch
for
s3,
and
so
we
see
s3
isn't
one
of
the
default
ones.
We're
gonna
drop
that
through
a
plug-in,
then
the
plug-in
will
handle
the
fetching
for
us.
C
Well,
how
do
you
do
that
cross-platform
somebody
wanted
to
do
that
say
in
a
go.
How
do
you
deal
with
cross-platform
binary
so
especially
when
you
get
in
and
then
how
do
you
deal
with
things
that
are
non
POSIX
because
we've
got
lots
of
people
are
writing
the
stuff
in
shell
scripts
and
things
like
that?
Well,
how
do
you
port
that,
over
to
Windows
lots
of
Windows
developers
aren't
using
bash
or
shell
scripts?
C
C
We
could
expose
it
this
way
and
then
we're
looking
at
packaging
updates
for
repositories,
a
complimentary
command
home
fetch
that
lets
you
push
into
a
repository
as
well
as
pull
which
we
have
today
and
the
plugins
would
let
you
you
know
you
could
push
to
a
repository
and
just
like
we
have
s3
colon
slash,
slash,
can
drop
down
to
a
plug-in
we're
looking
at
the
same
thing
for
push
as
well.
We're
also
looking
at
updates
to
the
packaging
schema
as
a
whole.
That's
not
really
included
here.
C
C
Actually,
when
we
looked
at
things
like
you
know,
and
one
of
them
is
user
stories,
and
so
we
even
look
at
what
is
a
package
manager,
because
we
found
that
a
lot
of
folks
were
having
trouble
identifying
the
inners
between
a
package
manager
versus
a
configuration
manager
versus
something
else
and
where
you
would
use
those
compared
to
other
things.
And
so
there
a
number
of
appendices
here
to
try
to
explain
that.
C
C
There
is
the
lightweight
ability
to
do
upgrades
so
there's
things
like
hooks
in
there
that
can
do
upgrade
so
you're
saying
I'm.
Moving
from
this
version
to
that
version,
maybe
go
run
a
job
that
then
goes
updates.
My
schemas
things
like
that
there
is
a
lightweight
capability
to
do
that.
Helm
is
not
trying
to
compete
with
operators
or
special-purpose
controllers
and
intimately
know
the
needs
of
every
possible
application,
and
so
well.
How
includes
a
lightweight
amount
of
this?
Probably
about
the
same
amount?
You
could
script
with
apt
in
Debian
packages.
C
If
you
want
to
do
something
complicated,
a
recommendation
would
be
to
use
something
like
operators,
in
fact
I
would
say
at
CD,
and
the
community
charts
has
an
Etsy
D
operator,
one
where
operators
are
used
along
with
helm
and
I
know.
The
folks
at
Oracle
are
working
on
my
sequel
operator
that
can
be
used
in
the
same
kind
of
way
and
we're
talking
to
them
about
how
that
could
fit
into
a
chart
as
well
and
I.
D
Certain,
like
kubernetes,
already
has
like
ways
of
ensuring
that
things
come
up
when
they
need
to
but
sort
of
in
a
larger
sense,
where
there's
a
little
bit
more,
where
it's
less
obvious,
I'm
wondering
sorry,
long-winded,
I'm,
just
I,
guess
I'm
just
curious.
If,
if
there's
been
any
thought
to
how
to
represent
dependencies
between
both
within
a
chart
like
this,
these
resources
comprise
an
application
deployed
by
this
chart.
Is
there
any
sort
of
annotation
or
way
of
identifying
that,
after
it's
deployed
helm,.
C
Has
the
notion
of
dependencies
and
the
dependencies
remember
right
come
up
before
the
application
itself
does,
and
so
every
chart
can
have
dependencies
and
dependency
versions
and
there
there's
a
requirements
file
and
a
requirements
lock
file
a
requirements
GML
to
specify
what
you'd
like
in
a
lock
we'll
lock
it
it's
kind
of
typical
to
a
dependency
manager
where
you
can
specify
a
version
ranges
and
then
you've
locked
and
pinned
to
that,
and
so
it
does
do
the
dependencies
on
other
charts
and
they
can
be
from
different
repositories
as
well.
But.
D
If
we're
trying
to
distribute
like
configuration
across
clusters,
there's
been
discussion
about
being
able
to
detect
when,
like
not
all
the
resources,
the
comprise
and
application
are
not
properly
targeted
at
a
given
cluster
and
therefore
the
application
would
not
be
able
to
run
because
it's
like
the
target
set
is
a
subset
of
what
actually
application
actually
needs,
and
so
it's
I
think
it's
maybe
I'm
sure
it's
outside
the
scope
of
town
but
I'm,
just
kind
of
curious.
If
you've
thought
about
how
to
represent
the
relationships
between
like
the
components
so.
C
One
of
the
things
that
we're
seeing
a
lot
in
charts
is
they
can
be
configurable
for
different
cases,
and
so
I
could
have
a
chart
and
with
one
set
of
values
it
may
take
WordPress.
It
might
stand
up
my
sequel
in
that
cluster
in
another
cluster.
It
might
use
my
sequel
as
a
service
and
then
pass
those
credentials
into
the
application,
the
same
chart
and
its
configuration
flags
and
the
values.
C
You
might
say
in
this
environment
use
this
set
of
configuration
for
Service
Catalog
to
consume
my
sequel,
and
this
other
one
send
this
other
set
of
configuration
and
it'll
set
up
the
appropriate
thing
in
each
place.
But
the
chart
is
capable
of
doing
more
than
one
thing
is
that
the
kind
of
thing
you're
getting
in.
D
Kind
I
mean
it's
be
honest:
I
haven't
I've,
been
blinders
on
I
haven't
been
considering
hell
more
how
to
install
things
more
like
once.
You
have
resources
in
the
cluster.
How
do
I
propagated
to
multiple
clusters,
but
I'm,
trying
to
trying
to
step
back
and
sort
of
see
how
they
could
interoperate?
Because,
right
now
it
seems
like
there's
just
like.
If
you
want
to
be
able
to
use
Federation
helm
would
be
be
difficult,
I
think
to
use
helm
in
combination
with
Federation,
which
I
think
is
very
suboptimal.
D
C
With
helm,
3
of
what
really
comes
out
of
helm,
3
is
the
it's
either
C
or
DS
or
secrets
that
are
done
in
the
cluster
and
then
kubernetes
normal
kubernetes
objects,
and,
and
that's
that's
it
so.
The
state
can
be
stored
using
standardized
methodologies
in
a
cluster
and
then
it's
just
normal
kubernetes
objects
that
are
going
to
be
there
with
nothing
running
server-side
for
home
3.
So
what
would
be
the
kinds
of
cases
where
that
would
be
a
problem
with
a
Multi
cluster
setup?
I
mean.
D
We've
been
discussing
the
primitives
of
Federation
being
like
a
template
and
a
way
to
parameterize
the
template
and
a
way
to
specify
which
clusters
the
template
should
be
just
or
the
privatized
template
should
be
distributed
to
and
so
helm
being
more
focused
on
creating
like
kubernetes
resources.
It's
not
at
the
level
of
abstraction
that
we're
targeting
specific
well,
how
would
we
step
back
and
be
able
to
use
helm
to
you
see,
I
mean
they're
kind
of
like
doing
parallel
things.
Only
Helm's
like
I
wanted
to
create.
D
B
I
can
I
just
interject
for
one
moment.
Firstly,
I
think
we're
kind
of
running
out
of
time.
Here
we've
got
quite
a
few
things
to
do,
and
so
I
would
suggest.
We
perhaps
schedule
a
follow-up
if
there
are
more
discussions
that
we
would
like
to
have
sounds
like
Murray's
interests
that
maybe
we
should
schedule
a
follow
up
discussion
and
then
a
very
brief
topic
on.
B
A
very
brief
comment
on
the
last
question
was
that
that
that
was
one
of
the
original
reasons
why
Federation
adopted
the
kubernetes
api,
because
we'd
enable
things
like
helm
to
to
deploy
things
into
Federation's.
So
just
a
comment,
I
think
we're
gonna
have
to
move
on.
We
got
Tim
on
the
agenda
next
Tim.
Are
you
here
and
ready?
I
am
here
yes
give
us
your
Rhode
show
cool
yeah.
E
And
hopefully,
that's
coming
through.
Also,
this
document
is
linked
in
the
agenda
document
as
well.
So,
basically,
what
we're
doing
to
contributor
experience
is
just
coming
out
to
each
of
the
SIG's
and
trying
to
share
a
little
bit
of
information
and
be
a
little
more
I
guess,
engaged
and
and
how
we're
discussing
and
messaging
things,
and
partly
that
this
comes
from
a
few
things
that
have
happened.
That
have
been
a
little
contentious
over
the
few
months,
but
also
that
we
just
want
to
be
getting
the
word
out
on
a
number
of
things.
E
So
that's
basically
why
I'm
hearing
I
kind
of
go
through
maybe
10
minutes
or
so
of
of
information
that
we're
wanting
to
share.
So
the
the
first
and
biggest
thing
the
mayor
is
just
alluding
to
is
that
we
are
working
to
make
changes
and
hopefully,
improvements
collaboratively
with
SIG's
across
the
kubernetes
orgs,
with
the
goal
of
giving
a
more
common
experience
to
contributors
across
the
organization
and
we're
where
this
has
gotten
a
little
bit.
Contentious
is
some
things
like
the
examples
at
the
top
of
the
dock
there.
E
E
So
there's
a
few
examples
that
are
around
some
things
that
are
currently
underway
issue
triage
guidelines
is
one
and
new
labels
and
colonizing
labels
is
another
one
that
are
currently
underway
and
and
really
we're.
Just
we're
looking
and
kind
of
being
here
to
just
say:
hey
if
any
of
you
have
thoughts
or
if
you
see
these
things
happening
and
you're
not
sure
if
or
whether
they'd
map
well
to
your
sig,
then
jump
in
the
conversation,
because
it's
a
conversation.
E
This
is
open
source,
it's
a
shared
project
and
we
as
a
as
a
community,
wants
this
to
work.
Well,
so
something
that
you
may
be
seeing
increasing
here
should
be
seeing
increasingly
around.
This,
then,
is
how
are
you
finding
out
about
changes
and
when,
when
do
the
changes
happen
so
like
mostly
stuff
from
the
project,
it's
a
lazy
consensus
model
but
where,
as
a
discussion,
maybe
winds
down
on
the
mailing
list.
So
like
kubernetes
dev
at
some
point
somebody
would
say:
okay,
here's
what
I
think
that
has
evolved
out
of
this
discussion.
E
Think,
as
you
all
would
know,
there's
the
the
rotating
set
of
SIG's
who
are
presenting
there,
but
hopefully
you
also
outside
of
your
presentation-
have
some
some
representation
there
and
are
are
seeing
what's
going
on
the
next
thing
that
we
wanted
to
make
sure
that
folks
are
aware
of
I
think
you
already
are
aware
of
because
that
was
just
tagged
on
the
end
of
the
agenda.
So
there's
a
new
set
of
Charter
templates
that
the
steering
committee
is
released
around
CID
governance
and
I'll.
Just
leave
it
at
that.
E
The
next
thing,
our
contributor
guide,
we
have
been
working
to
improve
the
contributor
guy
there's
links
there.
We're
also
looking
to
start
work
next
on
the
developer.
Portions
of
that,
so
there's
kind
of
we
feel
like
there's
two
breakdowns
of
information
in
the
guide.
One
is
like
I'm,
a
newcomer
to
kubernetes.
What
do
I
need
to
do
to
be
a
productive
member
of
the
community
and
collaborate
in
terms
of
contribution.
E
Mechanics
then,
there's
also
the
more
deeper
developer
side,
where
you're
trying
to
understand
the
design
of
some
particular
area
and
some
of
the
more
nitty-gritty
details
who
are
looking
to
next
start
cleaning
up
the
that
developer
portion.
But
a
bunch
of
work
has
gone
in
over
the
last
quarter,
a
kind
of
the
last
release
cycle
to
improving
the
contributor
guide.
E
The
next
large
set
of
topics
is
mentoring
and
our
call
to
action
here
I
guess,
is
for
the
individual
six
to
be
thinking
about
what
your
contributor
growth
strategy
is
from
the
contribute
side,
we're
doing
a
number
of
things
to
try
to
make
it
easier
for
the
community
to
grow
in
general.
But
it's
something
also
to
think
about
actively.
As
I
said
yourself.
E
So
a
couple
areas
called
out
here,
we
have
a
once
a
month
meet
our
contributors,
the
session
that's
going
on,
so
it's
a
zoom
meeting,
but
also
kind
of
overlapping
with
Twitter
and
slack,
so
that
people
can
ask
questions
and
get
sort
of
mentoring
on
demand.
Then
there's
a
couple
of
more
formal
programs.
Outreach
e
is
looking
like
it's
going
to
come
online
in
May
with
a
specifical
of
building
new
contributors.
E
If
there's
interest
from
this
SIG
definitely
reach
out
to
us
incurred
Trebek's
and
and
let's
see
what
sort
of
opportunities
there
are,
the
other
one
is
group
mentoring.
So
you
may
have
heard
of
this
over
the
past
quarter.
There
was
a
test
rollout
of
group
mentoring
in
a
test
cohort,
and
the
goal
of
this
was
to
have
a
structured,
formal
program
with
a
set
of
people
who
had
been
identified
as
candidates
to
move
up
the
contributor
level.
E
So
our
goal
is
not
just
to
grow
contributors,
but
also
to
grow
the
entire
sort
of
pyramid
of
developers,
so
that
more
contributors
become
reviewers
and
and
owners
and
maintenance,
and
we
get
the
the
benefits
of
scale
that
you
expect
an
open,
healthy
open-source
projects.
So
that
has
been
running
and
it
was
focusing
sig
cluster
lifecycle
initially
and
had
I
think
it's
ten
people
and
a
good
chunk
of
them
have
actually
gotten
up
to
the
point
where
they're,
probably
gonna,
be
reviewers
going
forward.
E
So
that's
looking
like
it
was
successful
and
we're
gonna
start
trying
to
roll
that
out
to
additional
cohorts
over
the
next
while
and
then
we're
looking
at
the
idea
of
a
buddy
program
to
get
a
little
more
intimately.
One-On-One,
if
say,
is
a
leader
within
a
saiga.
You
see
somebody
who's
in
need
of
mentoring
or
has
some
opportunity
growth
opportunity
within
the
group
and
you're
there's
something
that
you'd
like
to
delegate
to
them.
E
For
example,
maybe
setting
up
some
some
one-on-one
mentoring
there
to
do
a
handoff
in
a
building,
but
the
leads
engaging
a
little
more
proactively
to
build
some
aspect
of
their
community
into
what
they're
looking
for
for
for
growth.
The
next
topic,
then
I'm
slack.
If
you
have
any
questions
on
running
your
slack
channel,
there's
a
link
there
on
some
some
guidelines
and
contributes
can
can
help,
but
one
of
the
bigger
ones.
E
We
wanted
to
call
out
to
folks
because
we're
noticing
a
lot
of
SIG's,
don't
have
pinned
documents,
and
this
is
a
subtle,
simple
little
thing
that
you
can
do
to
make
it
easier
for
a
newcomer
who
joins
the
the
channel,
for
example
in
cig
multi
cluster.
In
the
description,
there's
a
link
to
the
meeting
agenda
document.
But
you
could
also
pin
other
things.
E
You
could
pend
links
to
other
information
commonly
asked
questions
or
your
issue,
current
issue
list
or
feature
list
or
different
things
like
that,
so
that
when
somebody
comes
along
late,
they
can
see
those
those
most
common
links
of
information
and
then
finally
user
office
hours.
So
in
a
way
this
is
kind
of
like
the
meet
our
contributors,
but
instead
of
being
a
contributor,
mint
or
focus.
E
This
is
about
people
who
are
using
kubernetes
and
have
questions
on
or
developing
the
kubernetes
have
questions
kind
of
across
the
gamut,
and
there
were
we're
asking
for
more
volunteers
to
help
in
fielding
the
questions.
So,
if
that's
something
that
you
might
be
interested
in
again,
there's
discussion
that
happens
on
slack
and
a
zoom
meeting
and
interaction
if
you're
interested
follow
the
link
there
and
please
volunteer
and
get
involved
and
then
yeah
that
was
that
was
basically
the
set
of
stuff
we
wanted
to
bring
out
to
y'all.
B
B
There
was
super,
useful,
I
think,
there's
a
lot,
there's
a
lot
that
to
digest
and
really
useful
for
you
to
put
the
link
in
our
notes.
There
and
people
can
read
up
on
the
detail
behind
some
of
that
stuff
and
come
back
to
you
with
questions
or
discussions
offline
thanks,
Tim.
That
was
awesome.
Thank
you
right
now,
you'll
learn
how
to
operate.
My
desktop
in
here.
Where
are
we
in
that's
right?.
F
B
G
G
G
For
Nord
is
it's
actually
fully
plans
for
Nord
and
it's
it's
a.
It
basically
means
to
like
spread
this
information.
So
if
you,
google,
it
you'll
see
like
a
logo
like
a
Ford
logo
with
the
Nord
spelled
on
it
and
various
references
to
that
Ruru,
maybe
it
would
actually
give
more
context
around
the
naming.
The.
G
You
yeah,
okay,
so
I,
guess
to
start
the
demo
I'm
going
to
join
together
both
of
these
clusters
to
be
used
for
the
multi
cluster
workload
and
to
do
that,
there's
a
tool
called
coupon
or
which
is
leveraged
from
the
original
cube
fed
and
basically,
what
this
is
going
to
do
here
and
it
looks
like
my
mappings-
don't
quite
work
in
this
shared
mode.
That's
strange.
G
Okay,
so
let's
go
ahead
and
join
we're
going
to
join
the
u.s.
West
cluster
into
the
u.s.
West.
We're
gonna
create
a
new
cluster,
join
it
and
name
it
u.s.
west
and
we're
picking
us
West
as
the
host
cluster
context,
because
that's
essentially,
where
we
have
both
the
cluster
registry
and
the
workload
API
server
and
controller
that
are
running.
We're
also
going
to
add
this
cluster
to
the
registry.
G
This
is
the
cluster
registry,
and
so
let's
go
ahead
and
launch
that,
and
some
of
you
may
be
familiar
with
some
of
the
things
that
it
would
do,
but
basically
it's
going
to
create
a
namespace
in
the
joining
cluster
and
create
some
arbok
and
service
account
in
order
to
access
the
resources
in
that
cluster.
So
go
ahead
and
join
the
US
east
as
well,
and
if
we
go
ahead
and
get
the
federated
clusters,
we
should
be
able
to
see
that
both
US,
East
and
u.s.
G
West
are
listed
here
and
let's
go
ahead
and
do
a
describe
on
them
and
we
can
scroll
up
a
little
bit
here.
We
can
see
that
US
East
has
been
joined
there.
The
cluster
is
ready
and
similarly
we
have
US
West
and
the
cluster
is
ready.
So
now
we
basically
have
a
set
of
clusters
that
we
can
run
some
workloads
against
and
then.
B
I
can
ask
a
very
quick
question
so
or
two
to
actually
the
the
first
one
is.
Could
you
just
clarify
the
distinction
between
the
the
context
and
the
actual
cluster
when
you,
when
you
register
those
you,
you
gave
the
same
cluster
name
twice
if
I
remember
correctly,
could
you
just
clarify
what
those
two
clusters
sure.
G
B
G
B
Neck
contacted
your
local
queue,
control
context:
okay,
cool.
The
other
question
was:
could
you
just
clarify
the
relationship
here
so
when
you
created
those
clusters,
you
ended
up
with
something
in
your
Federation
called
the
cluster,
but
it
sounded
like
there
was
a
cluster
registry
under
the
hood
somewhere.
Could
you
just
clarify
where
all
this
information
that
we're
looking
at
on
the
screen
now
lives
so.
G
This
information
is
part
of
the
federated
cluster
resource
type.
That's
part
of
a
Nord
part
of
the
workflow
for
creating
the
cluster
registry
was
to
have
a
list
of
clusters
that
you
could
potentially
add
to
a
workload
add
to
a
Federation
or
you
could
just
have
them
there
containing
some
sort
of
metadata
and
all
the
info
information.
This
is
basically
trying
to
kind
of
bring
them
together
and
show
how
they
can
co-exist
together.
G
Yes,
that's
correct,
so
we
need
a
way
to
bootstrap
ourselves
a
little
bit
here.
So
the
cluster
registry
did
not
have
the
list
of
clusters
to
begin
with.
They
could
have
been
pre-populated,
in
which
case
then
you
wouldn't
need
to
add
them
to
the
cluster
registry.
In
this
case,
because
everything
was
empty,
it
was
kind
of
a
fresh
start,
fresh
demo
here,
we're
gonna
boot,
strap
ourselves
so
provide
some
context
in
our
existing
cube,
config
and
also
add
them
to
the
cluster
registry,
while
we're
at
it
and.
D
B
D
D
B
G
Yeah
feel
free
to
if
you
have
any
other
questions
as
we
go
through
this,
so
the
next
part
of
this
kind
of
just
show
now
that
we
have
a
set
of
clusters
that
we
can
run
workloads
against,
there's
a
set
of
resources.
You
can
create
and
have
them
propagate
and
provide
different
rules,
and
so
right
now
we
support
federated
namespaces
secrets,
config,
Maps
and
replica
sets,
and
recently
we've
added
deployments
as
well.
But
for
this
example
we'll
leave
those
out.
G
So
you
can
see
here,
there's
kind
of
different
configurations
for
each
of
these
and
I
won't
go
into
all
them,
but
I'll
go
into
replica
set,
for
example,
and
some
of
you
may
be
familiar
with
some
of
the
docs
have
been
kind
of
going
around
documenting
and
showing
this
stuff.
But
basically
we
have
a
federated
replica
set
resource
type
here
and
it's
we're
just
going
to
name
it
test
replica
set
and
it's
gonna
go
in
the
test.
G
We
have
this
named
federated
replica
set
override
again,
it's
just
a
test
replica
set,
and
this
basically
allows
you
to
override
certain
fields
in
the
original
template.
So
in
this
case
we
want
to
override
the
US
east
cluster
name
to
contain
five
replicas.
Instead
of
the
three
that
we
specified
here
on
the
left
and
then
lastly,
we
have
federated
replica
set
placement
and
the
federated
replica
set
placement
is
another
resource
type
federal
resource
type
here,
and
it
allows
you
to
basically
have
rules
on
where
you
want
your
resource
to
be
propagated.
G
G
Okay,
so
now
that
we've
created
them,
we
can
go
ahead
and
see
how
they've
propagated
so
we're
just
gonna
loop
through
each
of
the
cluster
contacts.
It's
just
a
fancy.
Four
loop,
that's
going
to
loop
through
each
of
the
contest
context
and
we're
going
to
get
the
namespace
test
namespace
that
we
just
created.
G
G
You
can
see
the
test
secrets
similarly
and
then,
lastly,
which
is
probably
the
more
interesting
one
just
for
this
short
demo,
because
you
can
easily
see
the
varied
override.
You
can
see
that
US
East
has
a
test
replica
set
with
five
replicas
and
US.
Wes
has
three
so
that's
consistent
with
what
we
what
we
requested
so
that
kind
of
shows
how
they're
propagated
and
then
real
quick.
We
can
probably
we
can
show
here
some
the
ability
to
actually
move
resources
from
one
namespace
to
another.
So
let's
go
ahead
and
just
modify
the
Federated
namespace
placement.
G
So
now
that
that's
updated,
we
can
loop
through
and
see
that
the
US
east
no
longer
has
any
replicas
in
it
and
we
can
do
the
same
and
look
at
all
the
other
resource
types.
But
in
the
interest
of
time
I'm
not
gonna
go
show
them
all
so
in
order
to
bring
them
back.
If
you
wanted
to
bring
those
resources
back,
you
could
specify
US
East
again
that
we
want
the
resources
propagated
to
that
cluster
and
then,
if
we
loop
back
through
them,
we
should
see
them
start
to
be
scaled
back
up.
G
So
basically
this
that's
kind
of
concludes
a
demo.
I
mean
this
Finneran
prototype.
You
can
see
handles
the
workload
by
joining
the
clusters
into
the
workload
so
that
you
can
actually
specify
resource
types
that
you
would
want
to
propagate.
Then
you
can
actually
override
certain
parameters
that
you
want
to
differentiate
in
your
clusters.
The
way
we
did
with
like
replica
set
here
as
an
example,
and
then
you
can
specify
placement
rules
for
where
you
want
that
resource
type
to
be
propagated.
B
B
B
First
and
then
we
can
have
a
kind
of
a
Q&A
session,
but
basically
the
steering
committee
has
done
some
work
on
trying
to
kind
of
help.
The
SIG's
get
a
little
more
organized
in
general,
there's
a
wide
variety
of
SIG's
these
days
and
they
all
have
various
different
degrees
of
success
with
governance
and
publishing
you
know
who
they
are
and
what
they
do
and
who
to
contact
regarding
them,
etc.
B
So
they're
steering
committee
put
some
work
into
trying
to
kind
of
make
it
easier
for
SIG's
to
emulate
the
successful
SIG's
and
what
came
out
of
that
was
kind
of
a
template
for
a
sig
charter.
So
basically
standardizing
the
kinds
of
information
that
the
steering
committee
would
like
the
sinks
to
publish
and
the
ways
they
would
suggest
that
they
operate
themselves,
and
then
out
of
that
also
is.
Is
this
area
of
sig
repos?
So
there's
a
new
github
organization
believe
it's
called
kubernetes
six
and
under
there
there
are.
It
is
possible
to
create
repos
there.
B
A
set
of
you
know
basic
procedures
that
SIG's
need
to
go
through
to
put
their
repos
in
there,
and
so
that
that
is
essentially
open
for
business
these
days.
If
you
want
to
have
a
repo
that
is
not
part
of
the
kubernetes
corn
doesn't
necessarily
ship
as
part
of
the
standard
kubernetes
distro,
but
is
you
know
logically
work
that
is
being
done
an
island
by
a
cig?
B
B
B
B
H
B
H
B
B
B
H
You
know
important
akhil
is
not
here,
I,
don't
know
what
plans
he
had
migrated
I
know
that
initially
he
put
it
there
since
initially
the
work
that
did
was
for
TCP
ingress.
Specifically
as
far
as
I
know,
the
intention
is
not
to
make
it
the
only
for
TCP
ingress
but
I,
don't
know
yet
plan
to
move
into
the
the
kubernetes
things
repository.
H
B
Yeah
I
have
a
similar
discussion.
I
think
his
plan
is,
as
you
say,
to
to
have
it
support
more
than
just
Google
cloud,
in
which
case
it
probably
wouldn't
belong
where
it
is
right
now,
but
we
that
discussion
and
decision
until
it's
more
relevant
okay,
so
yeah
that
they
go
there's
some
reading
material
for
you
and
do
we
I
can
do
all
of
these
sagrado
refreshes
and
creation
of
relevant
repos
and
things
or
if
there
are
volunteers
out
there
who
would
like
to
put
the
PRS
together
based
on
the
templates
that
would
be
useful.
B
H
Is
it
better?
Yes,
yes,
okay,
so
two
things
that
I
wanted
to
mention
number
one
I've
been
having
trouble
lately,
uploading
the
sake,
videos
to
YouTube
for
some
reason,
the
recording
files
that
zoom
has
been
making
unprocessed
bull
by
YouTube,
which
means
that
quite
a
few
of
the
meetings,
it
was
one
last
a
few
weeks
ago,
which
I
just
uploaded
to
drive
and
shared
with
the
city.
H
At
this
point,
I
don't
necessarily
have
the
time
to
go
through
and
debug.
Why
exactly
that's
happening
for
all
the
videos,
so
there
will
probably
be
some
sick
videos
that
for
now
are
uploaded
to
Google
Drive.
If
somebody
has
the
cycles
to
go
through
and
attempt
to
convert
them
into
a
format
that
YouTube
can
use
and
upload
them,
I
will
certainly
add
them
to
the
lit
to
the
playlists.
H
But
I
noticed
that
at
least
two
of
the
meetings
from
the
past
few
weeks
have
had
that
trouble
as
well
and
I
was
unable
to
us.
I
was
unable
to
upload
any
of
the
three
videos
yesterday,
when
I
tried,
I'll
try
again
today
with
a
better
internet
connection
and
see
what
happens,
and
second,
there
was
an
announcement.
Last
week,
I
sent
a
mail
about
the
cluster
registry
becoming
a
CRD
I
had
no
negative
feedback,
and
so
Paul
has
been
prototyping
that
work
and
is
we're
probably
going
to.
B
F
B
Actually
start
to
interrupt
you
in
front
I
would
suggest
you
actually
just
punt
this
to
contra,
because
presumably
all
these
things
are
running
into
the
same
problems.
They
everybody
uses,
helm,
sorry,
how
users
home
uses
zoom
and
records
using
zoom
and
everybody
tries
to
upload
to
YouTube.
So
this
is
probably
not
specific
to
a
stick
at
all
so
yeah.
If
one
of
you
want
to
just
reach
out
to
big,
contributes
and
say
you
have
a
solution
for
us,
that
would
be
great.
H
B
Understand
what
I'm,
what
I'm
suggesting
is
that
that
I,
don't
think
our
signals
to
worry
about
it
at
all
so
only
hand
it
off
to
contrib
X,
and
if
they
don't,
you
know,
think
it's
their
mandate
find
out
where
it
is
in
the
hand
it
off
there,
because
it's
it's
not
specific
to
the
sig
as
far
as
I
can
determine
its
injuries.
Well,
I
can
I
can
contact
seeking
Trebek's
about
it
beautiful.
Thank
you.