►
From YouTube: Community Meeting, November 15, 2022
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
Okay,
everybody
welcome
to
the
community
meeting
on
November
15th
I
literally
had
to
recheck,
because
I
forgot
what
day
today
is,
as
always
feel
free
to
submit
any
issues
or
topics
that
you
would
like
to
discuss
and
issue
Drifter
submitting
that
one
also
here
on
the
chat,
Channel
and
without
further
Ado
I
would
like
to
start
with
the
first
big
topic,
and
that
is
cluster
workspace.
Redesign,
Stefan.
C
B
Cluster
workspaces
so
I
keep
talking
while
you
try
so
cluster
workspaces,
they
live
in
parent
clusters
and
when
going
to
farting
like
incrementing
sharding,
you
realize
quickly
that
looking
into
the
parent
is
a
bad
idea,
because
a
parent
and
the
subject
space
can
live
in
different
charts
or
different
regions.
Even
or
something
like
that.
B
So
depending
on
the
parent,
is
always
bad
the
scenario
and
for
other
resources
like
API
exports
and
schemas,
we
figure
out,
we
will
just
distribute
in
a
cache
so
to
have
a
disability
cache
wherever
this
shot
can
basically
eventually
consistently
access
and
see
everything.
But
for
workspaces,
that's
not
a
good
idea,
because
there
might
be
many,
so
we
thought
about
what
to
do
and
we
we
decided
Well,
there's
no
need
to
look
into
the
power
and
everything
we
need
to
to
answer.
A
request
is
in
the
workspace
itself
and
this
design.
B
Here
we
worked
on
that.
We
like
for
the
last
two
months
or
three
months,
and
we
had
at
least
two
meetings.
I
remember
we
talked
about
it.
It
suggests
a
new
data
model
more
or
less
about
workspaces
from
user
point
of
view.
It's
mostly
the
same,
but
internally
it
looks
different
and
yeah
I
think
you
can
now
go
to
the
other,
the
first
link.
B
So
if
you
want
to
read
details
about
what
changes
and
about
the
order,
how
we
implement
it,
that's
there
in
this
documents,
but
for
now
this
one
I
think
is
better
the
shows
the
data
model
change,
yeah
stay
there.
The
orange
boxes
are
the
ones
the
user
sees.
So
today
is
a
workspace
at
the
bottom
left
and
behind
it
there's
a
cluster
workspace
and
workspaces
is
the
user-facing
one.
Cluster
workspace
is
the
internal
one,
but
workspace
is
just
the
projection
of
cluster
workspaces
today.
B
So
when
you
create
a
workspace,
actually
you
create
a
cluster
workspace
in
in
NCT
to
know
that
a
cluster
on
the
right,
so
if
two
Dodger
investors
here
on
the
right
side-
and
they
have
some
screen
boxes
here
in
the
picture-
imagine
those
green
boxes
are
not
there
like
in
main
branch.
Today,
those
green
boxes
don't
exist.
Okay,
to
know
that
this
workspace
exists
on
chart
B,
you
have
to
look
on
the
left
on
the
orange
okay,
so
we
cannot
authorize
today
without
looking
on
the
parent.
B
So
the
first
idea
was:
let's
put
something
into
the
actual
cluster,
like
create
an
object
like
the
green
one
here
and
use
that
for
authorization
forget
about
the
average
for
authorization,
that's
what
we
have
done.
So
we
can.
We
know
ZX,
but
we
know
the
existence
of
a
workspace
without
looking
on
the
parent.
B
B
This
has
two
nice
properties.
I
mean
the
inside
okay,
so
we
can
also
rise
again
completely
independent
of
the
parent
cluster.
The
other
Advantage
is-
and
you
see
it
here
in
the
example.
The
cluster
role
binding
for
the
admin
is
not
a
special
thing
anymore,
as
it
was
before
your
members
workspace
content
resource,
which
was
artificial.
B
This
goes
away.
This
is
a
normal
cluster
hole
binding,
which
just
binds
a
user
to
Cluster
admin
as
a
whole
for
Access.
We
had
to
do
a
little
bit
different
things,
so
we
we
use
the
non-resource
slash
access
like
when
you
can
access
that
you
have
access
to
the
cluster,
but
as
before,
access
is
just
the
bare
minimum
to
enter
it,
doesn't
give
you
any
lead
access
to
anything
so.
D
B
Is
a
big
change
big
not
for
the
user,
the
user
will
still
see
workspaces,
but
at
least
for
controller
authors.
They
should
focus
on
this
workspace,
so
forget
about
cluster
workspaces.
B
B
Let's
change
some
changes
at
the
Top
If.
You
look
on
this
front
proxy.
So
the
front
proxy
is
basically
the
same
as
before,
but
it
has
to
know
both
kinds.
It
knows
about
this
workspace
and
about
workspace,
so
it
has
to
reconstruct
hierarchy
in
memory
by
looking
on
those
objects
from
all
charts
and
basically
you
can
map
again.
The
old
hood
call
on
something
workspaces
works
as
paths
to
the
actual
workspaces,
serious.
A
Just
a
small
question
that
refers
actually
to
the
access,
I
think
I'm,
not
sure
if
I
understood
it
correctly
today,
the
semantic
is
that
if
you
want
to
give
users
access
to
College
workspaces,
you
simply
buying
them
on
the
parent
workspace
with
the
access
pattern
right,
so
you
have
sort
of
like
one
one
point
of
entry
to
submitting
or
backend
gate
the
entry
for
users.
Now
you
have
to
do
it
per
workspace,
so
you
need
to
have.
B
The
yeah
right,
that's
true,
see
if
this
is
a
use
case.
One
can
think
about
other
ways
to
do
that,
like
we
can.
So
what
we
do
today
in
this
intermediate
step.
We
are
thinking
the
airbag
objects
from
the
parent
into
the
workspaces,
and
then
they
are
there
and
they
are
local.
You
can
talk
about
those
things
as
well.
If
it's
it's
a
strong
use
case,
a
big
use
case
yeah
there
are
solutions
for
that,
got
it
just
to
finish
up
before
we
go
into
questions
any
one.
B
Second,
just
yeah,
you
can
finish
one
thing:
you
see
here,
the
dev,
the
kcp
dev
cluster
annotation
in
every
object.
We
have
it
today
right,
but
today
we
write
a
root
codon,
something
there's
a
whole
path
into
that
field.
B
We
will
change
that
and
turn
it
into
an
ID.
So
basically
the
the
hierarchy
will
not
be
visible
by
that
anymore.
So
hierarchy
is
still
there
because
there
are
those
workspace
objects,
the
orange
objects,
so
you
can
reconstruct
the
hierarchy,
but
the
objects
in
a
in
a
luxury
cluster.
They
have
the
string
and
the
string
will
be
just
an
ID.
So
maybe
an
eight
character
or
12
character
or
something
base
36
string.
B
This
allows
us
later
on
to
move
workspaces
in
the
hierarchy,
for
example,
and
this
always
stays
the
same.
It's
it's
an
idea.
It's
like
you,
you
need
to
identifier
for
this
workspace.
This
will
also
come
and
another
thing.
Maybe
the
last
thing
you
see
when
you
look
on
the
right
workspace,
the
user,
colon
Lucas,
one
that
one
is
apparentless
workspace.
So
there's!
No
there's
no
orange
object
right,
there's
nothing
which
points
to
that
workspace,
which
means
this
is
powerless
and
it's
another
route.
B
B
Any
other
workspace
can
also
be
a
root,
so
this
I'm
sure
I
can
read
it
ljhg
and
so
on
so
there's
eight
character
string
on
the
right.
This
can
be
used
as
another
route.
If
you
want
to.
This
will
allow
us
to
decouple
user
homework
spaces
from
the
hierarchy.
So
this
logic
around
buckets,
Euro
member,
it's
very
complicated.
In
code
we
had
a
couple
of
bucks,
races,
basically
creating
this
hierarchy.
This
will
completely
go
away
with
the
homework
spaces
will
be
super
simple
after
that.
B
The
logic
to
call
this
thing.
User
code
on
lucash
is
actually
in
the
front
box.
So
just
an
Arias.
The
front
proxy
applies.
When
you
talk
to
user
code
on
lukash,
it
will
use
some
hashes.
In
the
example,
I
just
took
a
chart
224
and
space
36
offset
and
I
get
the
string,
and
this
is
basically
the
name
of
the
cluster.
So
that
way
we
can
add
new
routes.
If
you
want
to
in.
E
B
B
I
think
that's
it
so,
just
about
State
Andy
I
haven't
forgotten
you.
We
have
a
PR
which
creates
those
green
objects,
but
they
are
not
active
yet
like
when
we
merge
that
they
exists.
They
are
assumed
all
the
time,
but
they
are
not
used
for
sensation,
for
example.
Yet
there
will
be
a
second
PR
which
sends
which
is
around
basically
inverses
all
the
controllers.
B
D
B
C
I
just
want
to
say
we
are
soliciting
ideas
for
better
names
than
this
workspace
for
the
the
green
box,
so
we
could
call
it
logical
cluster.
There
was
a
suggestion
earlier
to
call
it
dot
workspace,
but
something
I
think
I
think
we'll
want
something
other
than
this
workspace,
because
it
is
confusing
when.
F
C
B
G
C
C
H
Yeah
I
was
wondering
if
we,
since
we're
not
encoding
the
hierarchy,
and
the
name
anymore.
Does
that
change
the
approach
needed
for
caching
workspace
types.
B
Yeah,
so
we
we
have
a
variant
of
the
design
and
we
maybe
this
is
a
good
topic
like
the
types
where
we
have
a
hierarchy
in
a
different
annotation.
If
we
need
that,
we
can
always
be
edit.
This
way,
I
think
what
you're
talking
about
basically
is.
We
cannot
walk
up
the
hierarchy
right
implicitly,
you
always
need
something
like
you
need
something
well,
founded
like
the
root
of
your
hierarchy.
B
This
works
well
in
Cube
Kettle,
two
cattle
can
just
keep
as
a
whole
string
and
also
here
on
the
left
side.
If
you
look
on
the
URL
of
the
orange
there's,
a
full
string,
so
if
you
have
that
you
can
walk
around
freely,
but
of
course,
if
you
just
point
to
this
workspace,
this
is
lost.
So
we
have
to
talk
about
that.
A
B
Yes,
yes,
and
no,
we
have
this
first
PR,
which
puts
everything
in
place.
Of
course,
there
are
changes
in
how
rocks
how
controllers
work
eventually
and
also
the
homework
spaces,
so
there's
code
in
our
second
PR,
which
looks
for
the
existence
of
the
old
home
first,
so
this
is
not
not
really
visible
suddenly,
but
of
course,
it's
still
in
this
bucket
highest
higher
key,
so
I
think.
Eventually
there
will
be
in
HD
Vibe
and
we
start
fresh.
B
A
B
A
Okay,
all
right.
Okay,
all
right
great
thanks
a
lot
any
comments
regarding
cluster
workspace
and
once
twice
all
right.
Then
next
Topic
kcp
in
the
box
with
run
charge.
If.
A
Right,
okay,
in
that
case,
we
are
skipping
over
to
proposed
new
kcpio
investigation
for
etch
multi-cluster.
E
Yes,
I
can
go
here,
so
we've
been
working
along
the
lines
of
building
out
the
new
edgemc
suborg
inside
kcb
Dev
and
one
of
the
areas
we
thought
might
be
useful
for
us
to
have
traffic
directed
towards
the
edge
multi-cluster
use
case
is
to
have
its
own
specific
investigation
inside
the
kcp.io
website,
and
so
to
do
so.
We've
come
up
with
a
preliminary
dock
that
would
be
represented.
That's
in
a
PR
there
number
18.
E
and
if
you
look
at
the
files
change
there,
so
the
one
it
basically
took
the
structure
of
the
the
transparent
multi-cluster.
We
went
ahead
and
redid
some
of
the
paragraphs
at
the
top
and
then
at
the
bottom.
There's
still
some
that
are
commented
out
that
we
still
haven't
gotten.
I
E
Know
entirely
fleshed
out,
but
we're
working
on
it.
So
I
wanted
to
know
if,
just
in
general,
if
this
is
a
useful
thing,
if
people
thought
that
this
is
something
that
might
be
supported
or
something
that
they
might
like
to
have
inside
the
kcp.io
website.
B
So
to
understand,
you're
talking
about
the
investigation,
talks
or
pasted
links,
those
which
are
living
here
today,
they
show
up
when
you
go
to
documentation
to
reference
or
something
you
have
an
investigation,
folder
or
something
on
the
left
side.
Correct.
E
D
D
And
you
also
mentioned
that
there
is
a
walk
to
kind
of
break
right,
the
monolithic
ACP
into
different
repositories,
so
in
the
future,
I
assume
that
still
investigation
on
each
of
those
areas-
right,
TMC,
tenancy
and
so
on-
will
end
up
in
this
kind
of
page
right.
You
are
not
going
to
open
it.
Yeah
I.
B
D
B
D
A
C
Go
ahead,
I
think
it
is
I,
think
that
the
kcpio
website
is
applicable
to
the
broader
umbrella
of
what
we
want
to
achieve
with
kcp
overall,
and
the
website
is
obviously
fairly
young
in
terms
of
age
and
structure.
C
So
we
will
evolve
it
over
time,
I
think
as
the
repository
split
and
we
have
a
kcp
core
and
a
TMC
and
so
on
and
so
forth.
The
website
will
gain
some
restructuring
as
well.
But
at
this
point
any
visibility
is
better
than
no
visibility.
So
I'd
say:
let's
just
find
a
spot
like
we
can.
We
can
put
in
that
investigation
spot
and
and
call
it
a
day
for
now-
and
you
know
we
can
post
about
it
on
social
and
try
and
get
more
people
interested
and
then
over
time,
restructure
as
needed.
A
Just
to
come
in
from
my
site,
because
I've
been
thinking
about
this
right
now
as
well,
I
think
restructuring
later
having
everything
in
one
spot
is
even
easier
than
Gathering.
All
the
topics
probably
is
carried
around
different
repositories,
so
also
a
good
argument.
If
I
have
this
on
the
kcpio
side,
all
right
sounds
good,
since
we
converged
against
the
consensus
any
more
comments
about
this
topic.
So
I
assume
this
is
sort
of
like
agreed.
A
Good
one,
okay,
good
right
in
that
case,
that's
that
tall
I'll,
stop
talking
about
this
topic
as
well.
If
anybody
else
has
comments
or
suggestions
regarding
the
additional
topics
on
the
Tio
side
and
now,
are
we
ready
for
kcp
in
the
box
with
time
chart?
Okay.
F
This
will
not
scale
basically
for
the
service
development
and
that
and
the
next
one
was
to
how
to
run
it
basically
fast.
If
I
need
to
do
a
stitch
or
some
to
somebody
or
even
for
simple
development,
so
I
started
working
on
the
health
chart.
Revamping
and
I
saw
Kyle
just
left
and
I
did
at
least
input,
but
basically
the
chart
itself
is
being
updated
to
work
on
the
public.
Github
images
and
I
was
thinking
on
adding
this
a
bit
of
it's
a
simple
shell
script
which
what
it
does
it's.
It's
installs.
F
F
One
is
for
the
root
cluster
to
try
and
set
manager,
decks
Ingress,
pointing
to
local
local
environment
utcd,
and
what
they
have,
in
addition
is
I
have
a
reverse
dialer.
So,
basically,
when
you
want
to
do
a
development
locally,
you
want
the
environment
to
behave
the
same
in
the
Q
cluster,
like
in
your
local
development.
So,
instead
of
like
pushing
images
and
things
like
that,
I
just
have
everything
in
the
same
Ingress
points
which
goes
through
the
reverse
diode
to
my
local
machine.
F
F
F
I,
don't
know
so
I
was
thinking
basically,
in
addition
to
helm,
charts
at
this
show
Machinery
to
the
helm.
Chance
repo
with
a
small
read
me
like
how
to
get
started
soon,
potentially
pointing
to
the
controller's
runtime
example,
as
a
as
an
example
to
run
via,
like
reverse
Island,
basically
how
you
would
do
that
outside
and
just
basically
wanted
to
open
for
this
question
what
people
think
about
this
foreign.
A
F
Is
that
it's
like
don't
get
me
wrong
like
running
locally?
It's
it's!
It's
always
better
when
you're
working
on
PCP
core
itself,
but
if
you
want
to
test
example
like
full
integration,
with
identity
Provider
from
proxy
the
virtual
stuff,
like
everything
in
one
box,
it's
like
I
found
a
few
issues
with
like
reverse
DNS
resolutions,
and
things
like
that
and
as
this
is
more
beneficial
for
somebody
who
works
to
use
kcp
in
their
stack
I'm,
not
developing
CCP
itself.
A
F
F
B
Go
ahead
so
I'm
not
against
different
methods
to
to
deliver
our
artifacts.
Basically,
but
my
question
is
always:
how
is
this
tested
and
maintained
like
when
we
change
something
like
we
change
the
clock
in
kcpe?
How
will
we
make
sure
this
doesn't
look
well
or
is
it?
Is
it
half
coded
to
a
version
or
something
like
that.
D
F
Latest
but
yeah
I
think
in
a
long
run,
the
helm
charge
should
be
pointing
to
the
release
version,
and
once
you
do
a
release,
you
basically
have
to
go
and
update
it
to
to
do
that.
I
suspect,
if,
if
the
bearish
in
Helm
chart
becomes
usable
as
a
delivery
method
of
that,
some
maintenance
will
be
required
there.
A
One
question
from
my
side:
I
think
kcp
can
be
set
up
and
configured
in
various
ways
right.
A
few
experimented
with
so
I
think
some
is
great
as
a
first
start,
however,
like
from
from
personal
experience
helmets
like
can
become
quite
limited
whenever
you
need
to
extend
beyond
the
you
know,
canonical
setup
with
some
basic
templating.
Have
you
experimented,
maybe
with
things
like
Q
or
Json,
to
provide
a
more
sort
of
like
approach
that
lets?
You
assemble
an
infrastructure
around
kcp
a
little
bit
more
Dynamic,
with
like
a
concrete
example.
F
Okay,
yeah
honestly
no
I
at
this
point.
Basically,
film
covered
my
use
cases
and
I
didn't
wanted
to
over
engineer
that,
because
that
wasn't
my
goal
like
the
goal
was
just
to
get
myself
running
fast.
So
I
can
develop
using
TCP
as
a
as
a
framework
and
like
when
the
changes
are
being
released
in
the
main
kcp
repository.
I
didn't
want
them
to
re-render
each
and
every
day,
basically,
and
pointing
to
latest
image,
helps
to
do
that
quite
fast.
A
Right
I
think
this
looks
cool
I
think
we
still
have
like
some
thought.
Food
of
thought
process
going
on
around
maintainability
I
guess
Stefan
is
coming
back
to
your
point
right
and
also
to
flexibility
with
yeah
looks,
looks
cool
at
first
sight,
I.
B
F
C
Yes,
so
assuming
we
do
want
to
keep
the
helm,
charts
repository
and
I,
don't
see
any
reason
to
delete
it.
We
do
need
CI
for
it
and
the
problem
we're
facing
right
now
is
we
don't
have
an
easy
way
to
run
containers
in
our
CI
environment.
The
way
that
you
can
just
like
use,
Docker
and
spin
up
something
so
I
know.
H
Like
it,
even
if
we
did
manage
to
do
a
like
fully
containerized
sharded
test
using
kind
or
something
similar,
I
think
the
point
at
which
you
have
like
five
shards
running
with
five
LCDs
and
test
clients.
I
was
concerned
about
the
size
of
that
all
together,
it's
hard
to
schedule,
something
that
needs
like
10,
vcpus,.
F
F
H
H
So
I
agree
that
I
think
helm
may
not
be
a
good
solution
for
managing
five
shards
I.
Think
Helm
might
be
a
good
solution
for
managing.
You
know
all
the
things
that
are
co-located
with
one
Shard,
but
in
general,
yeah
I,
think
more
thought
needs
to
be
put
into
how
we
would
test
with
five.
A
All
right
so
tldr
from
my
side
generally
looks
good
to
like
major
open
topics
are
CI
Readiness
and
the
question
around
maintainership.
A
F
A
Does
anybody
else
have
opinions
or
comments
around
home
charts
twice
once
okay,
let's
see
what
else
we
have
left
I
think
that's
all
the
topics
for
today
unless
somebody
wants
to
chime.
In
short,
turn.
A
D
Yeah
one
quick
kind
of
question:
slash
a
request:
I
find
it
very
hard
to
find
to
you
know
there
is
a
huge
amount
of
design
documents
circularly
around
people,
putting
on
private
Google
kind
of
Drive,
putting
it
on
Hakim,
D
now
and
so
on.
So
if
you're
in
a
middle
of
discussion,
it's
very
easy,
but
for
a
newcomer
they
just
want
to
see
you
know
a
list
repository
of
all
it's
impossible.
It's
very
hard!
You
end
up
on
links
on
documents
that
say:
oh
it's
not
up
to
date.
D
D
I
have
like
hundreds
of
kind
of
pointers
in
my
browser
just
to
maintain
the
those
documents.
B
Yeah
a
shout
out
to
a
pull
request
from
Paul.
Well,
it's
I
think
it's
a
pull
request.
Risk
process,
changes
like
what
is
2023
for
kcp
and
one
part,
is
about
enhancements,
I,
think
I.
B
Is
aside,
of
course
we
have
a
mixture
of
documents,
a
mixture
of
platforms.
We
use
to
talk
about
those
things.
If
you
want
to
open
that
exactly
so,
we
should
have
an
enhancement
repository
and
at
a
certain
maturity
level
of
an
enhancement.
There
should
be
a
quick
request
here
for
discussion.
B
I
think
that's
going
to
make
it
easy.
It
won't
make
Google
Docs
go
away,
I
guess
just
just
one
hint.
If
you
join
the
Google
group
of
kcp
I'm,
not
sure
everybody
has
done
that
the
public
one.
So
we
at
these
use
that
to
give
permission,
because
when
we
open
the
document
with
a
letter,
we
cannot
open
it
to
the
world.
So
we
use
that
Google
group
to
give
access.
So
maybe
just
check
that
this
is
the
case.
Any
MMI.
You
can
see
them.
D
D
A
C
So
at
last
week's
meeting
we
talked
about
lazy
consensus
on
those
pull
requests.
Assuming
there
were
no
serious
outstanding
issues,
I
don't
believe
there
are.
So
if
there's
any
any
unresolved
comments,
let's
make
sure
we
get
them
resolved
and
I'll
go
through
and
see.
If
this
thing
is
ready
for
merging
and
I
can
create
an
enhancements.
Repo
I
can
start
trying
to
move
any
docs
I've
created
into
the
shared
drive
and
over
time
as
time
permits
and
I
think
we
should
include
it
in
planning.
C
We
should
diligently
go
back
and
create
retroactive
enhancements
documents
for
the
major
features
that
we
already
have,
as
well
as
creating
new
ones
and
I
believe
that's
spelled
out
in
the
stock
as
well.
C
A
In
that
case,
if
there
are
no
more
commands,
I
would
say
we
continue
on
the
triaging
of
oncoming
issues.
Unless
there
are
more
comments
regarding
proposals
for
the
Google,
Drive
enhancement
proposals,
design
discussions
going
once
twice
and
let's
switch
over
to
the
incoming
issues,
bug
the
front
proxy
doesn't
expose
metrics
I,
recall
APR
Chris,
maybe
you
can
say
a
word
or
two
regarding
the
response
in
progress.
C
A
J
So
I
can't
remember:
we
mitigated
this
I.
This
came
out
because
I
was
working
on
deleting
crds
that
get
left
over
when
all
the
API
bindings
and
exports
are
gone,
and
we
mitigated
that
particular
problem,
but
I
don't
think
conceivably.
You
could
still
get
a
panic
in
other
ways,
because
there's
still
the
code
where
the
Panic
is
still
in
the
in
the
cube
Fork
but
I,
don't
know
if
that's
something
that
we
actually
would
be
considered
in
scope
for
kcp.
B
Stephen
has
there
been
any
investigation
whether
Panic
kill
some
poses,
because
if
this
is
the
case,
we
must
fix
that.
That's
a
very
important
issue.
B
C
B
H
B
Which
should
catch
those
things
if
it
doesn't,
somebody
has
to
investigate.
Why
not.
C
C
I
C
A
I
A
Cool
so
much
around
bugs
and
the
rest
is
features
create
an
incluster
authorizer
to
avoid
checking
with
parent
workspaces,
recall
Stefan.
Is
this
something.
B
A
A
C
I
asked
Chris
to
file
this
because
there's
I'm
not
intimately
familiar
with
the
metrics
packages
Upstream,
but
there
is
a
legacy
registry
and
there
is
a
non-legacy
registry
as
far
as
I
can
tell
only.
The
Legacy
registry
seems
to
be
used.
But
yes,
you
know
I'd
say
this
is
like
low
priority
or
backlog
priority.
So.
A
I
Can
Shed
a
little
light
on
this
one,
though,
because
I've
been
heavily
involved
in
the
observability
subsystems,
both
upstream
and
notebook
shift.
The
legistry
Legacy
registry
is
called
Legacy
registry
because
it
is
initialized
as
a
package
initializer,
which
is
generally
discouraged
in
general
all-the-go
programs
out
there.
The
there
is
a
cap
Upstream
to
move
away
from
this
idiom
and
not
to
initialize
the
Prometheus
registry.
As
a
you
know,
static
variable
inside
a
package
that
says
like
funky
side
effects.
A
If
there
is
interest,
I
can
put
pointers
to
the
cap.
How
to
do
that?
How
to
accomplish
that?
It's
you
know,
the
idiom
is
don't
initialize
The
Primitives
registry
as
a
static
variable,
just
dependency
injected,
and
the
controllers,
wherever
you
need
to
expose
metrics,
essentially
how
you
should
do
things
that
maybe
that
clears
things
up,
but
it's
yeah
it's
kind
of
low
priority,
but
it
you
know,
as
a
good
citizen,
probably
a
a
good
first
issue
or
a
low
hanging
fruit,
so
to
say
so:
backlog
or
technology
right
yeah.
A
Maybe
the
person
here
we
go.
G
Yeah
right
so
in
any
multitudinal
system,
you
need
to
draw
the
you
need
to
decide
where
you
draw
the
line
for
the
boundaries
of
isolation
right
and
we
draw
some
line
in
the
current
implementation
and
we
can
draw
different
lines.
So
this
is
this
issue
to
capture
what
we
want
to
do
in
the
future,
about
DNS
and
isolation,
specifically
about
DNS
in
here
I,
don't
think,
that's
critical,
that's
not
very
important,
so
could
go
to
the
backlog
most
likely.
If
you
think
it's
something
interesting.
A
That's
related
to
the
discussion
of
isolating
the
Sinker
on
the
target
clusters
from
yeah
other
workloads
right
so
I,
guess
that
was
a
big
discussion
around
Network
policies,
and
this
is
around
like
one
method
that
adds
it,
namely
using
via
the
same
service
right.
K
Yes,
Stephanie,
if
you
want
to.
G
I
I,
don't
think
maybe
I
don't
know
how
to
do
this.
How
to
ex
expose
this
it
could
be
when
you
create
a
new
workspace.
G
Maybe
you
decide
that
the
isolation
is
going
to
be
less
strong
than
than
for
other
workspaces.
I
mean
I
I,
don't
know
what
the
user
experience
is
going
to
be
right,
but
it's
the
idea
of
offering
some
configuration
options
in
a
you
know:
around
resolutions
for
admin,
people
right.
K
Yeah
I
think
I
think
we
should
probably
go
through
I
mean
based
I
mean
this
issue
is,
is
great
because
you
know
it's
a
way
to
track
the
question
and
then
probably
we
should
have
some
design
sessions
really
related
to
that,
especially,
you
know
to
know
how
it
you
know,
because
there
there
are
two
things
here.
It
seems
to
me.
One
thing
is
the
DNS
consistency
inside
a
workspace
and
the
namespaces
of
a
workspace,
which
is
what
has
been
worked
on
currently
so
first,
we
we
want.
K
We
might
want
to
configure
that
you
know
to
allow
some
namespace
some
namespaces
from
different
workspaces
to
be
able
to
discuss
together.
K
K
A
All
right,
okay,
put
it
on
backlog
list.
This
entry
I
think
there
is
another
topic
around
Milestone
epics.
There
is
one
point,
basically
API
priority
and
fairness
for
kcp
I,
don't
know
what
to
do
with
that
one!
It's
an
open!
You
can
you.
C
C
It's
going
to
take
a
while
to
get
our
two
approaches
merged
together.
He
he
did
a
lot
of
excellent
work,
getting
kind
of
half
the
puzzle
in
place
that
I'm
working
on
the
other
half.
So
it's
still
going
to
take
some
time,
but
we're
actively
working
on
it.