►
From YouTube: Kubernetes Federation WG sync 20180606
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
B
Okay,
let's
start
so
yeah
last
meeting,
we
had
some
some
work
items
which
we
basically
need
to
didn't
need
to
have
a
look.
So
one
of
the
items
was
I
mean
which
I
did
take
a
pause
I
had
to
check
if,
if
it
is
easy
to
implement,
support
for
multiple
binary
is
building
multiple
binary
into
queue
builder.
So
the
way
it
is
done,
I
haven't
given
I
mean
I,
haven't
done
a
lot
of
in-depth
research
but
high
level.
It's
like
queue
builder
has
some
automated
yeah
Mel
generation
kind
of
a
thing.
B
So
what
it
does
is
it
generates
Yambol,
and
it
can
also
create
a
docker
container
which
can
be
pushed
to
a
specific
place.
So
some
tweaking
of
this
code
would
be
needed.
It
won't
be
too
much
of
an
effort
yeah,
but
maybe
maybe
a
week
or
two
a
preferred
for
one
person
to
do
that.
So
it's
certainly
doable
like
it's
not
like.
It
will
be
too
much
of
an
effort
if
you
have
to
do
this
and
create
multiple
binaries
for
different
controllers.
B
D
B
I
was
coming
to
that.
That's
the
next
point,
which
is
noted
in
two
days
Olinda.
So
she
she
did
like
we
had
I
did
create
one
issue
earlier
and
I
think
you
also
have.
You
also
have
one
issue
which
talks
about
single
country
kind
of
a
thing
for
components.
So
there
are
multiple
ways
this
country
could
be
there,
so
one
is
about
API
server
like
if
we
are
using
the
aggregated
approach.
We
have
the
API
server
in
the
API
server.
There
is
a
possibility
that
at
a
given
point
of
time,
the
API
server
event
starts.
B
It
exposes
only
certain
amount
of
API
is
not
all
and
which
can
be
controlled
by
a
flag.
This
is
certainly
doable
if
we
are
going
to
the
CID
based
approach.
In
that
case,
it
will
be
the
installation
of
the
CID.
So
whichever
object
he
had,
your
resource
is
created
against
the
chaos
api
server,
that
that
is
what
the
user
sees.
Both
of
these
the
configuration
is
sort
of
already
there.
We
don't
really
have
to
do
much
for
API
control
or
control
of
the
API
switch
gets
exposed
to
the
user
in
controller
manager.
B
D
B
Okay,
the
next
one
that
I
did
list
over
here
is
like
I
and
Shashi,
both
actually
faced
like
I,
did
go
through
a
cycle
where
I
had
implemented
my
controller,
which
was
replica
idling
preference
controller,
and
it
all
worked.
Fine
and
miroo
you
for
known
reasons,
you
basically
change
the
informer
and
some
portion
of
the
code
to
work
with
dynamic
client,
and
that
also
means
that
the
most
of
the
stuff
had
to
be
changed
to
use
unstructured
object.
So
using
the
ants.
B
The
dynamic
client
to
some
extent
is
okay,
but
using
the
unstructured
object
and
then
dealing
with
it
and
setting
some
fields
in
that,
and
maybe
getting
information
out
of
the
unstructured
object
seems
to
be
a
lot
more
dirty,
I
would
say
and
I
think
it's
quite
our
own,
also
because
each
if
there
is
no
check
on
that.
So
it's
not
a
structure
that
we
are
dealing
it.
We
are
sort
of
dealing
with
plain
Cyril,
I
Jason.
That's.
D
But
in
terms
of
like
how
you
interact
with
in
structured,
you
can
just
build
a
wrapper
around
it.
That
you
know
gives
you
access
to
the
things
you
want
in
a
type
safe
way.
I
mean
that's
what
we're
doing
for
things
like
placement,
since
placement
is
basically
homomorphic
across
all
types.
It
just
has
the
list
of
clusters.
D
All
you
need
is
a
method
that
translates
you
know
between
the
unstructured
field
and
the
list
of
clusters
or
a
slice
of
clusters,
so
I'm
not
being
prescriptive,
I
mean
if
you
feel
that
a
federated
Informer
that
doesn't
use
unstructured
be
desirable,
my
hope
would
be.
Is
we
could,
rather
than
having
two
entirely
parallel
paths,
we
would
have
the
ability
to
support
either
dynamic
or
typed
client,
because
there's
a
lot
of
shared
code
in
there.
Yes,.
B
Yes,
yes,
I
said
so:
yeah
I
mean
I.
This
is
not
a
pressing
requirement
as
of
now
because,
as
you
mentioned,
and
that
there
are
mechanisms
of
ways
of
translating
from
unstructured
to
a
particular
object
that
kind
of
stuff.
So
we
have
done
some
gimmicks,
but
I
find
that
code
is
not
just
clean.
It's
not
like
real
code,
which
should
we
should
use
and
when
we
are
moving
to
say
beta
or
something
right
now
it
might
just
work.
It
might
be
fine.
So
this
is
something
like
we
basically
maybe
need
to
do
long
term.
D
B
D
D
B
D
D
C
D
Not
really
like
the
Federated
Informer
previously
was
implemented
very
similar
to
kubernetes
in
forests,
where
the
instantiation
would
include
functions
that
would
provide
type
specific
behavior.
The
change
here
was
moving
to
use
the
dynamic
client
which
it's
still
a
specific
like
it
still
requires
some
configuration.
It
just
meant
that,
rather
than
using
like
the
Federation
client,
it's
using
the
dynamic
client
rather
than
dealing
in
in
objects
that
are
kind
of
like
just
a
generic,
implement
eight
a
generic
interface
for
a
very
specific
interface
below
it.
It
uses
unstructured,
which
is
just
a
bag
of
data.
D
B
E
E
D
I'm
not
saying
you
don't
I'm
not
happy
to
have
help,
but
not
expecting
people
to
sign
up
for
the
work,
in
other
words
other
than
like
review
and
etc.
So
there's
a
walkthrough
we
have
most
of
that
done.
It's
going
to
have
to
be
updated
during
the
transition
to
queue
builder
and
the
part
that
is
kind
of
half
done
a
test
script
that
exercises
the
walkthrough
like
the
deploy,
Federation
script
kind
of
does
it,
but
the
goal
is.
D
The
goal
is
basically
as
a
step
towards
getting
into
n
testing
and
CI,
which
we
do
not
have
yet
making
sure
that
and
then
testing
is
at
least
reproducible
locally
like
easily
so
run.
This
script
run
the
tasks
pane.
You
can
melon
a
DVD,
so
our
perspective
is
that's
kind
of
a
good
starting
point.
There's
not
a
lot
of
stuff
that
we're
testing
today
to
me
that
isn't
tested
and
integration,
but
you
do
want
to
have
that
capability
in
hands
of
developers,
if
not
in
CI
we're
not
notice
on
the
list.
E
D
D
B
B
D
D
Probably
if
you
want
to
do
like
e
to
e
and
CI
we're
gonna
need
to
be
a
to
Q
test
and
try,
and
that
is
going
to
be
a
little
bit
more
complicated,
if
only
because
of
the
coordination
overhead.
With
the
testing
for
work,
so
where's
its
you
know,
Travis,
you
just
go
and
do
stuff
on
her
own.
When
we
move
to
Cube
suddenly
we're
gonna
need
to
coordinate
pretty
closely
with
the
chest
and
her
people
I.
Think.
B
That's
it
I
I
meant
yeah
I
meant
not
doing
that
test
in
faster,
because
I
think
doing
that
is,
will
take
us
quite
quite
quite
much
more
time
compared
to
so.
B
D
C
D
D
C
C
E
B
B
E
Managed
GE,
which
is
as
muriatic
was
trying
to
say,
is
the
same
as
the
integration
test.
So
it's
a
bit
duplicate.
It's
duplicating
that
behavior
right
now
and
that's
something
we'll
look
to
combine
in
the
future
to
make
sure
we're
only
running
through
one
set
of
tests,
it's
just
running
through
a
different
framework,
but
it's
ideally
gonna.
The
IDI
should
ideally
be
testing
the
unmanaged
infrastructure
once
we
get
there.
E
D
Tldr
is
that
in
the
future,
the
end-to-end
tests
will
be
expected
to
run
against
both
the
integration,
fixture
and
sort
of
the
deployed
configuration,
and
the
goal
is
just
having
one
set
of
tests
to
manage
but
being
able
to
execute
them
against,
like
environments
with
various
levels
of
detail.
So
quick
doesn't
actually
provide
you
with
an
entirely
realistic
scenario,
run
slower,
but
actually
the
full
cluster
right
now
we're
kind
of
duplicating
stuff,
but
it
it's
awfully
good.
Oh.
C
B
D
On
this,
so
we
have
n
dentists,
which
will
validate
the
features
work
against
a
deployed
kubernetes.
The
goal
in
terms
of
walkthrough
is
actually
from
nothing.
It
will
deploy
kubernetes
in
a
configuration
you
know
with
Mini
Cooper,
darker
and
darker
it'll,
install
Federation
controllers
and
types,
probably
ultimately,
via
C
or
D,
and
then
it'll
run
the
tests.
D
So
the
goal
is
actually
making
sure
that
the
like
the
goal
that
that
script
would
follow
as
closely
as
possible
the
user
documentation,
and
it
would
be
a
way
of
you,
know
validating
that
it
would
actually
work
for
the
user.
Not
just
oh
I
can
get
it
working
on
my
machine,
but
no
the
instructions.
We
have
have
some
degree
of
automatic
verification
so
that
the
users
don't
come
back
to
us
and
say
hey.
It
doesn't
work
for
me.
That
makes
sense.
Yeah.
D
B
D
B
B
D
I
think
there's
there's
good
progress
on
that
front.
It's
going
to
have
to
be
evolves
in
the
transition
to
queue
builder,
so
I
think
we're
just
keeping
it
on
the
list
to
make
sure
that
we've
we've
polished
it
up
like
it's,
not
there's
not
no
work
like
love
to
do
it's
mostly
done,
but
we
definitely
have
things
to
do
after
cute
builder
plans
and
and
obviously
we'd
like
you
know.
D
If
people
want
to
review
it
and
give
us
feedback,
we're
certainly
trying
to
find
people
who
are
less
familiar
with
Federation,
to
give
it
a
look-see
and
give
us
feedback
both
internally
and
externally
and
same
with
getting
started
I'd.
It's
it's
just
making
sure
that
we're
we're
leaving
time
or
remembering
that
we
still
have
some
work
to
do
to
get
the
documentation
done.
Pre-Alpha.
B
D
Cr
D
and
Q
builder
yeah,
so
I'm
Ivan's
been
working
on
Q
builder
for
a
while
now
he's
scheduled
to
go
on
pto
next
week,
so
I'm
kind
of
joining
that
effort
the
goal,
but
we
found
another
reason
in
Lindsay's,
been
working
on
getting
a
cluster
interest.
3
the
C
or
D
edition
of
cluster
industry
integrated
into
Federation
v2
and
in
the
process
we've
discovered,
there's
just
hassle
around
dependencies
and
that
was
added.
D
So
I'm
kind
of
I'm
working
on
that
full-time
as
of
now
and
the
goal
is
to
probably
do
the
new
to
cluster
registry
C
or
the
addition
and
Q
builder
kind
of
we're
kind
of
joined
at
the
hip.
I.
Think
because
we're
moving
new
ad
queue
builder
will
reduce
the
footprint
of
dependencies
such
that
there
won't
be
conflicts
that
word
we're
seeing
with
the
current
PR.
B
Yeah
so
via
said,
some
talk
with
it,
because
if
we
say
we
need
to
move
the
infrastructure
to
queue
builder,
then,
basically,
all
the
controllers
have
to
have
to
change
some
infrastructure
code
right
now
we
are
using
something
some
mechanism,
not
starting,
even
in
the
controller
and
that
kind
of
stuff.
It's.
D
Very
largely
similar
I
mean
I'm
I'm
I'm.
If
you
want
to
participate,
I'm
happy
to
have
your
contribution,
I'm,
not
sort
of
antistick
on
tribution.
So
for
me
it's
a
matter
of
migrating
all
the
types
over
making
sure
they're
all
deploy
and
tests
and
making
sure
the
controller's
still
work,
but
I
think
the
major
thing
that
for
coop
the
controllers
is
going
to
be
the
way
the
use
of
the
clients
might
change
to
some
degree.
But
I,
don't
think,
there's
gonna
be
a
huge
like
it's
gonna
be
work
but
I.
B
Agree,
thank
you.
What
you're
saying
so
most
of
the
code
remains
similar
for
controllers,
but
some
infrastructural
code
like
how
the
controllers
are
started
or
how
the
binaries
and
that
kind
of
stuff
might
be
different,
yeah
in
terms
of
API
like
so
why
I
said.
That
is
because,
at
some
point
of
time,
we
we
are
going
to
use
the
same
for
Apple
right
and,
at
some
point
of
time
being,
might
need
to
sort
of
flip
or
switch
over
to
the
new
infrastructure.
B
D
E
D
Going
like
yeah
the
point
of
transition,
I'm
gonna
coordinate
like
with
you
and
Shashi,
and
the
folks
on
our
side
and
anybody
else,
who's
doing
work
and
try
to
get
everything
that
is
like
major
into
the
tree
and
then
cut
over
I
mean
I.
Don't
honestly
I,
don't
the
most
of
the
work
from
what
I
can
see
is
just
in
the
type
transition
like
moving
to
the
new
generated
like
types
as
a
base
and
then
copying
the
functionality
over.
B
D
Yeah
yeah
I'm
not
intending
to
do
piecemeal
stuff
because
it
it
looks
like
it's
an
all-or-nothing
thing
just
because
of
the
dependencies
so
kind
of
anything.
Overall,
you
know
work
on
this
branch
and
at
the
time
that
you
know
I'm
getting
close,
then
I'll
start
seeing
how
we
can
get
everything
into
the
tree
so
that
it
minimizes
disruption
for
others
who.
D
D
That
ruining
a
new
fragmentation,
it
does
impose
a
cost
and
all
Asian
Ivan's
currently
investigating
that,
and
we
should
have
something
that
is.
The
hope
is
that
we
get
something
that's
basic
as
functional
as
we
have
today.
I
think
that's
achievable
having
something
that
does
more
validation
may
have
to
wait
for
dry
run,
which
is
the
112
timeframe,
but
should.
D
Yes,
that's
a
good
question:
I
mean
for
anything
that
requires
more
than
field
level,
validation
that
would
employ
a
web
hook
and
so
like
it
or
not.
That's
kind
of
the
cost
of
C
or
D
izmir.
We're
gonna
get
good
at
writing.
Web
hooks
and
I
hope
it'd
be.
Is
that
over
time
we
end
up
writing
kind
of
a
framework
for
a
web
hook,
validation
so
that
having
a
new
type
isn't
a
matter
of
doing
custom
work.
It's
a
matter
of
just
leveraging
existing
efforts,
but
from
the
starting
point,
it'll
be
like.
D
Oh
I
need
to
perform
more
than
field
level.
Validation
like
the
relationship
between
fields,
which
is
not
something
open.
Api
specification
allows
for
in
terms
of
defining
relationships
between
fields.
Then
you
need
to
write
a
web
hook
and
like
go
code
kind
of
you
know
it's
a
certain
amount
of
friction
there
previously
to
just
write
a
function
and
it
would
be
called
by
API
machinery.
Now
you
have
to
implement
a
web
hook,
make
sure
it's
deployed
and
and
point
to
that
web
hook
in
your
CRD
configuration
tomorrow.
D
A
D
A
Did
also
small
proto,
but
at
the
moment
I
cannot
share
that
the
repository,
because
it's
not
so
nice
and
I
need
to
clean
up
a
little
bit.
It's
not
incredibly
difficult
to
do
that.
The
problem
is
the
bigger
prom.
I
think
is
a
certificate
or
rotation
that
at
the
moment,
I
did
not
implement
and
there
are
not
a
huge
amount
of
documentation
for
that
I
think
is
feasible
because
of
East.
Your
folks
are
not
doing
that.
If
I
understood
correctly
that
the
repository
okay
I
came
investigate
and
I'll,
let
you
know
yeah.
D
D
So
it
is
a
moving
target
that
I
would
expect
like
in
the
six
months
between
now
and
four
five
or
six
months,
there
were
many
until
we
get
to
beta
I
would
expect
that
we
would
have
a
solution
for
validation
and
it
was
simpler.
What
we're
anticipating
today
and
in
terms
of
dry
run,
like
probably
the
future,
will
be
both
dry
run
and
webhooks.
Webhooks
are
needed
ability.
Any
functionality
is
Federation.
Specific.
The
dry
run
would
be
more
for
validating,
embedded
type
in
a
template.
I
have
a
like
a
deployment
embedded
in
a
deployment.
D
Template
I
would
ideally
be
able
to
pass
that
deployment
to
a
dry
run
like
validation
and
I,
would
not
know.
I
mean
I,
wouldn't
have
to
duplicate
that
validation
in
any
way.
I
would
just
say:
is
this
valid
and
think
you
would
come
back
and
say
yes
or
no?
The
same
good
thing
with
C?
Are
these
like?
If
I'm
a
user
implement
you
know
a
web
hook
for
my
validation
using
dry
run,
we
can
tie
into
that
local
validation
trivially.
You
don't
have
to
write
any
special
case
handling
or
whatever
recall
the
way
over
ourselves.
B
Okay,
that
seems
like
a
reasonable
walk
around
I'm
more
concerned
with
with
the
functionality
it
shouldn't
be
difficult
for
the
users
or
they
shouldn't
get
like
we
already
have
money
to
with
which
is
like
we
don't
have
necessary
defaulting
in
Federation,
and
then
that
it's
also
basically
created
and
okay.
This,
then
it
can
I
mean
it
can
fail
because
of
not
know
necessarily
defaults
over
there.
I
find
that
more
bigger
an
issue
compared
to
this
kind
of
stuff.
D
B
D
B
D
D
If
I
wanted
to
create
a
namespace-
and
it
would
contain
only
you
know,
the
set
of
applications
or
the
single
application
needed
to
go
to
this
set
of
clusters
rather
than
having
to
define
placement
for
every
single
resource,
which
could
be
kind
of
exhaustive,
I
could
just
say:
I
want
all
resources
in
this
namespace
to
go
to
these
clusters.
So
it
doesn't
the
goal
isn't
to
limit
the
fine-grained
control
that
is
currently
in
place.
It's
just
to
relax
the
requirement
for
users
that
don't
need
that
sort
of
fine-grained
control
and
I
guess
for
me.
B
D
Think
for
me,
I,
wouldn't
necessarily
gating
or
not
dating
like
for
me.
It's
a
priority
just
because
I
think
the
having
a
very
simple
UX
to
start
is
advantageous
and
also
would
hopefully
get
people
thinking
of
the
idea
of
application.
Boundaries
serve
as
a
precursor
to
maybe
considering
adoption
of
the
application
CRD
that
the
apps,
the
apps
egg
is
this
working,
so
yeah
you're
right,
but
it
I
mean
it's
not
critical.
It's
a
nice
to
have,
but
for
me
I'm,
like
I'm
I'm,
still
thinking
it's
important
and
I
want
to
get
it.
D
B
C
Well,
so
any
template
substitutions
there
might
be
default,
template
substitutions
that
apply
per
namespace
and
basically
any
any
defaulting.
So
if
we're
gonna
have
defaulting
at
some
point
with
the
defaulting
be
global
or
everyone
in
the
Federation
or
would
the
defaulting
potentially
be
the
namespace
and
it.
D
D
Decides
like
where
things
go,
and
so
I'm
not
saying
that
we
don't
want
to
approach
that,
but
I'm,
not
anticipating
that
as
a
near-term
goal.
If
you'd
like
do
you
think,
that's
the
feature
you'd
like
to
have
and
I'd
be
happy
to
discuss
it
or
like
add
an
issue
and
we'll
prioritize
it
etc.
Certainly
sounds
useful.
I'm,
just
I
haven't
really
thought
about
it.
Yeah.
D
B
D
D
I
mean
once
we
go
alpha
I
think
the
idea
was:
is
that
we'll
probably
the
sketch
like
we'll
probably
want
to
release
like
subsequent
alphas
like
bug,
fixes,
or
you
know,
alpha,
2
or
whatever,
whatever
so
we've
all
is
just
getting
in
restructuring
place
to
make
that
release
procedure
easy
and
I'll?
Do
you
see
that
will
carry
over
to?
Let
me
actually
do
you
know
beta
beyond.
B
C
E
D
C
B
D
Guess
is
just
impressive
yeah
we
should
have
support
for
any
of
those
types
and
I
mean
as
far
as
simple
propagation
goes,
especially
when
you
see
are
these
the
old
core
enemies.
I
mean
we're
doing
it
with
queue
builders.
So
it's
you
know
niceties
with
clients,
but
if
the
user
wanted
to
just
write
some
C
or
DS
to
represent
it,
the
template,
placement
and
optionally,
the
override
you
can
do
that
with
row.
D
Writing
any
code
just
apply
animal
to
a
cube
server
and
the
way
it's
written
I
mean
you
write
those
the
series
for
the
primitives
and
then
you
write
the
Federated
type
config
that
references,
those
and
then
a
propagation
controller
will
automatically
be
started.
So
it
can
be
actually
totally
actually
gone
to
the
point.
You
don't
have
to
write
code
to
propagate
things.
D
Yeah,
no
you're
right,
it's
good
to
be
able
to
say
we
support
these
out-of-the-box
anymore.
You
know
here's
a
procedure.
You
have
to
do
to
support
things.
We
don't
immediately
support
what
I
mean
the
long-term
strategy.
I
think
hopefully
pre-beta
is
that
we
actually
generate
CR
DS
for
all
these,
and
we
can
we
get
up.
We
could
either
do
with
it.
D
You
know
be
a
configuration
or
we
can
do
it
on
demand
or
automatically,
but
we
could
literally
feder
ate
every
single
cube
type
without
having
to
write
code,
and
so
the
goal
would
be
getting
to
beta
I.
Think
if
and
saying,
if
you
want
to
fetter
eat
something,
you
know
create
this
API
resource
that
says:
I
want
to
federate
this
thing
and
then
all
of
the
primitives
required
and
the
configuration
required
will
be
created
automatically
for.
B
E
F
B
G
D
My
my
assumption
was,
but
it
would
you
kind
of
be
like
like
say:
Service
Catalog
today
will
do
a
release
when
cube
does
a
release,
and
so
similarly,
like
the
cross
cluster
service
discovery,
when
Federation
doesn't
release,
they
would
do
release
maybe
in
advance,
and
then
the
Federation
release
would
actually
reference
the
image,
because,
presumably
would
there'd
be
some
way
to
start
the
controller
in
Federation.
It
would
say,
run
this
yeah
all
the
references,
this
specific
image
that
it
was
published
as
part
of
the
release
for
that
repo.
Does
it
make
sense,
I.
E
D
Mean
you
know,
I
think
it's
it's
fine
to
have
it
in
a
personal
repo.
As
long
as
you
don't
mind
that
it
I
mean
like
to
me
like
the
idea
that
you
have
to
have
it
at
an
org
I
think
the
main
reason
you
want
to
have
it
in
August
for
legal
reasons.
So
once
you
move
into
the
kubernetes
work,
then
you
wanted
contributions
from
other
people
and
there's
no
legal
implications
of
that.
And
if
you
don't
under
the
kubernetes,
org,
there's
kind
of
a
process
that
minimizes
the
potential
for
Wheatland
problems.
D
C
G
G
C
My
understanding
they're
actually
just
trying
out
this
fossa
tool,
so
it's
intended
to
check
the
licenses
of
all
dependencies
in
a
given
repo
and
determine
whether
it
thinks
that
they
are
all
compliant
and
I.
Don't
think
that
it
is
giving
any
of
our
repos
at
the
moment
or
a
clean
bill
of
health
at
all,
so
I,
don't
think
you
need
to.
You
know,
consider
the
cure
special
that
you're
failing
any
faucet
tester
they're,
only
just
piloting
it
now
so
I
would
just
go
ahead.
C
D
Cool
so
one
more
issue
that
I
put
on
the
agenda:
I
should
label
is
winning
but
as
part
of
the
transition
to
queue
builder
I'm
gonna
have
to
basically
touch
every
single
existing
type,
and
it
occurred
to
me
that
this
might
be
a
good
time
to
consider
removing
the
federated
prefix
from
resources
and
I
guess.
I.
E
D
Ration
it
all
for
doing
that,
you
discuss
it
a
pass,
but
is
to
revisit
it.
One
is
that
it,
it
just
adds
Robo,
City
and
I'm,
not
sure
giving
them
really
group
green,
a
group
inversion
and
API
why's
that
they
don't
really
necessitate
that.
So
it's
just
like
federated
secret
versus
a
secret
template
or
a
secret
placement
versus
federated
secret
placement.
I,
don't
know
if
that
adds
a
lot
of
value
and
I
wanted
to
bring
it
to
the
group
before
I
put
in
a
lot
of
work
to
change
it.
So
I.
D
I
am
I,
guess
I
I
wasn't
clear
on
that
and
momentum,
just
kind
of
carried
through
so
I'll
make
sure
that
gets
removed
in
the
transition.
Yeah
every
is
okay
with
type
template,
so
like
secret
template,
which
is
what
we've
been
referring
to
all
this
time.
Anyway,
it
was
kind
of
confusing
it
was
called
a
federated
type
versus
a
type
template
I.
C
Guess
my
only
concern
there
is
that
the
template
is
is
actually
the
thing
inside
that
thing.
So
so
the
thing
that
is
currently
called
a
federated
secret
actually
has
a
template
inside
it
or
pod,
which
reflects
the
kubernetes
secret.
So
calling
the
outer
type
a
template
is
maybe
not
the
right
thing.
I
would
recommend
just
calling
it
a
secret.
That's.
B
Yeah
I
remember:
Quinton
I,
remember
this
discussion
on
that
he
did
happen
and
it's
somewhere
in
the
notes.
I
tried
to
find
it
out.
The
decision
that
he
did
take
was
that
this,
whatever
is
called
federated
secret
right
now,
which
Maru
you
are
suggesting
naming
secret
template
would
remain
as
federated
secret
and
everywhere
else
like
in
over
the
a
door
placement
wherever
federated
string
is
unnecessary,
it
would
be
removed.
So
eventually
the
three
resources
will
become
like
federated
secret,
secret,
override
and
secret
placement.
D
I
guess
we
have
kind
of
a
trade
off
it's
either.
We
call
something
like
a
template
explicitly
which
couldn't
you
don't
seem
to
be
happy
with,
or
we
have
a
difference
in
the
naming
scheme
between
template
and
placement
and
override
and
I
personally,
I,
don't
know
like
what
do
you
think
Quentin
is,
is
avoiding
the
duplication
of
the
template
name
worth
having
a
inconsistent
naming
scheme.
C
No
I
mean
I,
don't
like
either
to
be
honest,
but
and
to
be
clear
that
the
reason
I'm
not
worried
about
the
duplication
of
template.
It's
the
fact
that
there
are
actually
two
different
things
that
are
logically
called
template.
There's
the
template
inside
that
thing
and
then
the
wrap
around
the
template,
which
we
are
now
also
calling
a
template
and
I
personally,
just
find
that
confusing
and
and
the
thing
that
you're
proposing
to
call
secret
template
is
not
just
a
template
because
it
actually
has
a
bunch
of
other
things
in
it
too.
C
D
D
E
D
That
there-there's
a
minor
reason
I'm
not
saying
this
is
a
justification
for
continuing
to
do
that.
I
tried
in
the
move
to
using
the
dynamic,
client
and
unstructured
having
common
like
having
a
spec
like
some
types
like
secret.
Don't
have
a
spec
hugging,
a
spec
as
the
entry
point
to
the
data
used
to
create
like
the
target
resources
for
a
given
cluster
means.
There's
no
special
casing
that.
C
D
No
I
agree
I
agree,
but
but
at
the
same
time
I
mean
for
the
few
types
that
bought
the
trend
and
is
C
secret.
The
only
one
always
config
now
also
kind
of
dumb
that
way.
But
if
those
are
the
only
two
types
I
mean
there
could
be
the
case
that
we
want
a
special
case
behavior
for
those
two
types
which
is
possible
right
and
then
each
types
back
would
there's
some
dumb
thing
around
like
as
we're
not
strictly
speaking,
it
gets
into
the
the
metadata
I
think
is
what
complicates
it.
D
D
D
No
I'm
saying
leave
the
context
I
think
like
having
it
called
a
secret
template
to
me,
makes
sense
and
then
whether
we
in
the
future,
move
to
having
a
secret
template
actually
look
exactly
like
a
secret
instead
of
the
complication
with
having
it
look.
Exactly
like
a
secret
is
like
the
metadata,
because
the
secret
template
is
not
a
secret
and
it's
API
version
and
kind
will
reflect
that.
C
I
agree
with
you
that
that
you
know
we
can
discuss
it
all
we
like,
and
if
we
can't
get
it
to
work
in
practice,
it's
academic,
so
I'm,
fairly
happy
I
just
wanted
to
make
sure
we
haven't
missed
a
trick
there,
as
far
as
for
the
actual
name
of
this
wrapper
thing,
whether
it
be
federated
secret
or
secret
Tim,
if
I
understand
correctly.
The
only
reason
why.
C
It's
mostly
about
name
clash
resolution,
so
there
would
be
relatively
little
reason
why
we
sorry
I
see
something
going
on
here.
I
can't
get
rid
of
it
right
now,
so
because
of
some
complication
in
queue
control.
If
I
stand
correctly,
you
can't
have
things
in
different
namespaces
with
the
same
name,
which
seems
to
completely
blow
my
mind
why
we
name
spaces
in
the
first
place
if
they
have
to
have
unique
names
in
them.
C
B
B
B
C
D
Yeah
I
think
it
uses
the
discovery
endpoint
you
go
and
look
up
that
kind
and
if
there's
an
ambiguity,
that
it'll
complain
and
I,
think
that
suggests
that
if
the
danger
is,
if
you
were
to
add
a
new
resource
called
the
secret
suddenly,
that
would
confuse
if
you
just
wanted
to
use
the
original
secret
keep
control
of
you
like,
but
there's
more
than
one,
and
so
it's
not
just
that
affects
the
UX.
For,
like
your
new
kind,
it
actually
affects
I.
Think
the
UX
for
anything
called
what
your
kind
is
called.
D
C
I
mean
the
main
point
I
guess
I
was
getting
to
is
how
do
we
know
that
secret
template
is
unique
to
us
like
it
doesn't
say
anything
about
Federation?
Isn't
it
no
way
of
guaranteeing
that
anybody
else
is
not
going
to
use
it,
and
and
if
you
expand
that
across
you
know
all
the
different
types,
the
probability
of
a
name
cache
becomes
even
bigger.
So
essentially,
what
we
need
to
do
is
reserve
some
patent
name
patent
and
say
this
is
ours
and
we're
consistently
using
this
name.
C
Generate
those
unique
names,
how
do
we
make
sure
that
our
name
is
unique
so
in
that
world,
like
federated
secret,
seems
like
a
better
choice
than
secret
templates?
Just
because
we
can
put
federated
on
the
front
of
everything
we
can
say
anything,
that's
prefix
of
federated
is
ours
and
we
don't
think
anybody
else
is
going
to.
C
You
know
create
federated
Secrets
outside
of
the
multi
cluster
Federation
working
group
and
therefore
we
can
ensure
name,
uniqueness,
I'm,
less
convinced
if
we,
if
we
have
things
like
secret
template
and
I
presume
that
applies
to
secret
placement
and
other
things.
Those
are
far
less
obviously
Federation
specific
names.
We.
D
C
C
D
A
C
What
is
it
not
a
lot?
No
space
group
API
group
is
X,
and
so,
whenever
I'm
username
mean
X,
unless
you
can't
find
it
in
X
then
feel
free
to
go
and
find
an
alternative
in
one
of
the
other
API
groups
and
then
you'd
never
get
clashes
and
you
basically
have
a
priority
of
API
groups
and
you
find
the
highest
priority
one
and
that's
the
one
you
use
and
then
all
of
these
problems
go
away,
but
I'm
not
about
to
like
fix
that
in
the
eight
minutes
we
have
left.
E
With
Quinton,
it's
not
ideal,
but
I
think
until
this
gets
addressed
and
it's
probably
gonna
become
a
larger
issue,
as
CR
D's
become
more
mainstream.
If
somebody's
not
already
working
on
something
like
that
seems
like
you,
should
be
able
to
specify
a
default
namespace,
which
you
can
today,
as
well
as
like
a
default
API
group.