►
From YouTube: Community Meeting, June 7, 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
All
right
so
welcome
to
the
kcp
community
meeting
on
june.
7Th
agenda
is
still
short,
so
if
you
have
topics
just
add
them
and
yeah
we
have
the
usual
ones.
Maybe
I
go
over
the
first
two,
so
we
have
protect
the
0.5
release
I
for
one,
so
we
needed
a
second
try
because
there
was
something
broken
in
image
building.
I
think
so
it's
alpha
one.
A
We
have
close
all
milestones,
so
all
epics
are
closed
or
they
have
moved
to
the
next
epic.
If
they're
multi-epic
already
multi-release,
that's
fine.
So
we
have
the
usual
task
about
open
issues,
but
we
as
usual
put
them
at
the
end,
and
we
have
three
topics.
B
Think
we're
spending,
I
think
that's
great.
I
did
want
to
say
a
thank
you
to
everyone's
work
on
0.5.
That
stefan
was
pointing
out
that
we
closed
out.
There
was
a
lot
in
there.
Our
our
themes
were
advanced
scheduling
and
finishing
up.
Some
service
account
work
and
exploring
staple
apps,
and
we
got
that
we
got
the
advanced
scheduling
closed
out.
The
location
api
mvp
was
in
there.
B
We
had
items
for
usability
and
app
authoring
with
the
essay.
The
service
account
cube,
configs
crd
snapshot
command
as
the
usability
improvement,
the
code
generating
wrappers
for
clients
and
informers.
That's
awesome
and
another
really
cool
one
in
the
api
evolution
phase
was
adding
authorization
for
restricting
access
to
objects
of
an
api
binding,
another
really
cool
thing,
but
even
more,
there
were
numerous
refactoring
pr's
in
there.
B
If
you
go
through
the
change
log
that
there
were
race
conditions
being
fixed
bugs
and
tests
being
fixed
and
added
and
more
off
work
that
we
didn't
even
capture
on
the
themes.
So
thank
you
to
everyone's
work
on
zero.
Five
there's
also
nine
first-time
contributors.
So,
if
you're
on
the
call,
welcome
and
thank
you
for
joining
the
adventure
but
on
to
0.6.
A
D
I
missed
the
beginning
of
it,
so
I
think
we
have
identified
all
of
the
folks
that
will,
you
know,
be
able
to
give
us
the
best
story
in
regards
to
the
storage
mobility
work.
You
know,
I
think
it's
one
along
the
lines
of.
Is
it
possible
to
get
some
time
with
you
know,
paul
andy.
Stefan
rob
just
someone
to
make
sure
that
what
we're
identifying
as
tasks
that
we'd
like
to
hit
are
kind
of
what
you
guys
are
expecting
similar
to
what
openshift
does
in
the
epics
and
sprint
planning.
A
A
We
just
skipped
the
topic
about
planning
and
design,
so
this
week
is
meant
for
those
meetings,
so
invite
people
interested
in
topics
and
talk
through
them
exactly
with
the
goal
you
described
like
coming
up
with
an
epic
which
is
scoped,
and
maybe
a
demo
workflow,
where
you
see
how
it's
used
afterwards.
So
this
is
exactly
the
topic
for
this
week
and
I
think
paul
will
talk
about
that
after
the
other
technical
topic
is
this:
okay,.
D
Sounds
great,
I
believe
guy
has
already
identified
a
couple
of
those
initial
topics
that
perfect
okay,
perfect.
So,
let's.
A
Postpone
that
to
the
v606
planning
in
a
few
minutes
so
before
we
do
that
mike,
you
have
a
question
about
pdf.
E
Well,
I
just
put
it
on
the
agenda,
I
mean
we
could
talk
about
it.
E
Now
or
I
mean.
E
All
right
so
yeah
I
mean
there
is
this
feature
you
know
in
kubernetes
called
api
priority.
In
fairness,
it
is
a
generalization
of
the
older
max
in
flight
filter.
It
is
about
regulating
concurrency,
which
is
one
step
more
advanced
than
regulating
rate.
E
So,
if
you
just
regulate
qps
you're,
assuming
that
the
cost
to
serve
every
request
is
the
same,
which
is
really
not
true,
so
the
maxin
flight
filter,
it
is
adding
the
the
recognition
or
it
kind
of
takes
one
step
beyond
that
and
says:
okay,
let's
suppose
that
the
cost
to
server
request
is
proportional
to
the
time
to
serve
the
request-
and
you
know
the
average
of
rate
and
duration
is
occupancy.
E
So
that's
why
regulating
occupancy
takes
care
of
regulating
both
rate
and
duration
together
in
a
natural
way
and
apf
follows
in
that
way
and
it
adds
a
customizable
first
off
it's
configurable
and
it's
got
rather
than
the
fixed
two
concurrency
pools
of
the
maximum
fly
filter
that
that
has
two
concurrency
pools,
one
for
reads,
and
one
for
rights.
Apf
has
a
configurable
set
of
concurrency,
pools,
configurable
classification
and
adds
concept
of
queuing.
E
Okay,
sorry
now
we
have
realized.
You
know
from
experience
that
that's
this
regulating
concurrency
still
is
is
falls
down
or
falls
short
of
in
a
reality.
In
a
couple
of
important
cases,
one
is
the
maxine
fly.
Filter
did
not
even
make
any
attempt
to
regulate
long-running
requests
in
any
way,
and
that
includes
watches-
and
you
know
my
initial
hypothesis
was,
if
you
regulate
the
other
stuff,
the
watches
will
kind
of
follow.
E
Putting
some
regulation
in
the
watches
is
potentially
somewhat
problematic
was
a
concern
that
I
had
in
apf.
We
added
regulation
of
watches,
and
we
also
responded
to
something
that
was
observed
in
practice,
which
is
that
when
you,
some
of
the
list,
requests
the
ones
that
return
really
long
lists
are
exceptionally
costly
amongst
requests
of
the
same
duration
or
similar
duration.
E
So
we've
made
two,
you
know
adjustments
or
special
considerations
beyond
just
regulating
concurrency
one
is
regulating
or
just
recognizing
that
some
requests,
particularly
lists
with
a
long
result,
can
be
expect,
especially
expensive.
E
So
we
handle
that
by
saying
they
can
rather
than
occupy
one
unit
of
concurrency
occupy
a
general
number
of
units
which
we
call
seats
of
concurrency
and
for
watches.
There's
two
considerations:
one
is
to
recognize
that,
as
you
may
recall,
in
a
watch
and
depending
on
the
parameters,
it
may
start
with
a
burst
of
notifications
to
to
bring
the
client
up
to
speed
with
the
existing
state,
and
in
that
case,
that
burst
is
an
exceptional
cost
and
then
there's
the
regular
cost,
which
is
not
really
synchronous
with
the
watch
request.
E
But
it's
synchronous,
roughly
synchronous
with
the
other
write
requests.
So
what
we've
done
is
we've
made
added
some
additional
consideration,
which
is
basically
seed
occupancy
for
a
write
request.
We
extend
its
seat
occupancy
in
the
logic
in
apf,
in
proportion
to
the
number
of
corresponding
watch
clients
anyway.
So
that's
the
outline
of
the
way
that
works.
You
know
I
asked
how's
that
going
to
work
in
kcp.
E
You
know
I
think
currently
and
there
is
no
special
consideration.
It
seems
likely
to
me
that-
and
I
think
stefan
responded.
You
know
a
similar
thought
that
this
is
we're
going
to
have
to
have
something
like
that.
That
is
a
cognizant
of
workspaces
and
the
configuration
in
individual
workspaces.
A
E
A
A
bit
just,
let
me
finish
the
sentence.
Maybe
the
challenge
maybe
is
a
bit
different
than
in
cube
in
cube.
The
workload
is
on
a
cluster,
it
won't
move,
it's
always
there
and
then
it's
a
question
about
distributing
the
computational
network
power
of
the
api
server
to
all
the
people.
In
the
fair
and-
and
I
mean
their
property-
is
what
you
want
to
reach
like.
Okay,
exactly
something
like
that,
so
you
want
to
to
to
share
it
in
a
sensible
way.
Let's
say
here:
the
user
does
not
know
on
which
charts
the
user
is.
A
The
workspace
is,
and
you
shouldn't
care
whether
they
are
noisy
neighbors
and
whether
they
are
1
000
users
on
their
chart
or
100,
or
just
10
or
users
alone.
So
I
think
we
need
something
which
is
more
absolute
and
understandable
by
a
user
and
translate
that
maybe
into
p
and
f.
So
that's
totally
fine.
So
if
you
can
use
that,
that's
fine,
in
other
words,
I
think
what
p
and
f
there's
one
property
or
one
one
restriction
of
p
and
f.
A
I
think
you
used
to
get
siege
right,
a
seat
in
in
the
scheduling
mechanism.
The
the
width,
the
size
of
the
seat,
is
not
understandable
by
a
user
right,
so
there
can
be
many
seats
and
you
get
10
of
them
or
they
can
be
just
few
seeds
on
the
whole
cluster
and
you
get
10,
but
those
can
mean
much
more
than
if
there
are
many.
E
All
right,
so
let
me
unpack
that
a
bit.
So
one
question
is:
how
does
the
capacity
of
the
server
get
configured
and
I
I
think
that's
the
one
of
the
central
ideas
here,
which
is
in
plain
cube.
There
is
one
cluster
with.
Basically,
we
assume
one
administrative
team
that
understands
the
load
on
the
cluster
and
the
that
team
we
support.
E
So
in
with
the
existing
apf
feature,
I
forgot
to
mention
that
that
side
of
it
the
capacity
side,
so
the
way
it
works
is,
as
you
may
recall,
in
the
old
max
and
flight
filter.
There
are
a
couple
of
command
line
parameters,
the
max
requests
in
flight
and
the
max
mutating
requests
in
flight
that
simply
configure
the
two
concurrency
pools.
E
What
we've
done
in
apf
is,
we
simply
add
those
two
numbers
together
and
their
sum
is
the
concurrency
limit
for
the
the
cluster
and
then
the
the
way
it's
this
division
is
configured
there
is
a
division
into
configured,
concurrency
pools,
it's
based
on
relative
weights.
So
there's
these
things
called
priority
level
configurations.
E
E
So,
yes,
those
are
configured
in
a
relative
way
and
it's
all
relative
to
command
line
parameters
and
right
so
for
kcp,
it's
more
likely
that
the
right
vision
is
that
for
each
workspace
or
shard,
or
something
like
that
right,
there
there's
some
kind
of
unit
of
isolation
there
you
would
want
to
assign
an
absolute.
You
know
concurrency
limit
and
then
have
that
divided.
You
know,
within
that
unit
the
seat
is,
is
actually
is
comprehensible
to
user.
Basically,
a
seat
is
an
ordinary
request
being
served.
E
The
exceptions
are
that
for
a
list
because
they're
exceptionally
heavy.
We
suppose
that
those
might
occupy
more
than
one
seat.
You
know,
but
the
baseline
model
is
a
user,
comprehensible
concept.
I
think
the
point
you're
making
here
is
the
capacity
side.
It
really
needs
to
be
adjusted
for
the
kcp
setting
so
yeah.
Let's
talk
about
that.
E
So
with
that
unit
of
sort
of
a
capacity
assignment
or
absolute
capacity
assignment
with
that,
because
I
see
this
work
on
there's
an
evolution
path
here
for
workspaces
right,
so
they're
they're
becoming
more
and
more
soft
and
adjustable.
A
A
It's
just
the
number
of
workspaces
you
create.
You
have
a
quarter,
maybe,
but
overall,
I
guess
from
a
billing
point
of
view,
if
you
want
to
build
a
service
on
top
of
that,
your
credit
card
is
charged
by.
I
know
so.
Many
seats
like
10
000
seats
per
month,
or
something
or
a
million
whatever
seats
in
your
sense
right
and
those
seats
which
you
buy,
by
which
a
credit
card
are
basically
distributed
over
your
workspaces.
E
E
So
in
that
sort
of
scenario,
then
I
think
well
I
mean
you
tell
me
right.
You
know
like
like
directories
right
if.
C
E
Create
subdirectories,
I
don't
have
to
you,
know,
sign
up
for
new
charges
on
my
credit
card
and
it
doesn't
give
me
additional
quota
so.
A
They
are
different,
they
are
different
models,
I
mean
the
simplest
model
is
maybe
per
per
directory
per
workspace.
You
have
quarter
and
the
more
complex
distribution
is
over
all
your
workspaces
right.
Those
might
make
sense.
Maybe
if
I
have
a
production
application.
I
wanted
her
workspace
right,
because
this
is
important,
but
for
everything
else,
which
is
not
what
maybe
I
want
an
overweb,
coder
cultural
sense
of
gps
or
seats
or
whatever.
E
Right
so
it
might
be
simplest
if
we
we
did
have
a
you
know,
an
absolute
concurrency
limit
per
workspace.
But
now,
if
you
start
talking
about
sharing
between
workspaces,
we're
talking
about,
then
it's
it's
some
some
other
unit.
What
would
that
unit
be
or
or
do
we
just
not
want
to
go
there.
A
A
So,
okay,
maybe
to
make
it
concrete,
so
we
do
planning
for
zero
six
in
a
minute
can
we
find
a
scoped
variant
of
that
which
we
can
implement
like
an
arp
and
errors?
That's
of
course
an
obvious
step,
but
also
bring
in
this
capacity.
E
E
Need
some
way
of
assigning
the
concurrency,
we
might
call
it
a
concurrency
quote
or
concurrency
limit
per
workspace.
You
know,
there's
there's
a
number
that
needs
to
come
from
somewhere
for
each
workspace.
E
You
know
apf,
as
a
I
kind
of
mentioned,
is
configured
by
these
explicit
objects.
You
wish
today
are
cluster
scoped.
We
would
want
them
to
become
workspace
scope.
Well,
I
guess
they
kind
of
are
because
that's
just
the
way
objects
work,
so
each
workspace
would
would
get
its
own
set
of
these
objects,
so
that
would
be
a
mod
there's,
currently
a
controller
in
the
server
that
creates
these
objects.
It
would
have
to
be
modified
to
create
a
set
of
these
objects
for
each
workspace.
E
Administrators
can
modify
these
set
of
objects
within
each
workspace
would
be
the
idea
I
mean
currently
and
again,
there's
a
controller
that
provides
a
default
set
of
these
objects
and
administrators
can
change
the
set
of
these
objects.
We
would
change
the
controller,
so
it
provides
a
set
of
these
objects
per
workspace.
An
administrator
can
change,
oh
by
the
way
ap,
since
there
is
a
controller
that
provides
the
objects
that
takes
place
over
time.
E
So
apf
is
defined
to
have
some
baseline
behavior
in
the
absence
of
any
config
objects
and,
of
course,
there's
a
defined
behavior
as
config
objects
are
added.
So
that
kind
of
answers
the
question
of
what
happens
to
a
workspace
that's
been
created,
but
the
objects
have
not
yet
been
created.
A
G
There's
probably
a
higher
level
thing,
though,
as
well
right
because,
like
since
the
priority
and
fairness
that
we're
trying
to
accomplish
here,
our
scope
to
a
single
shard
like
just
taking
the
controller
behavior
that
currently
exists
for
a
cluster
and
then
making
it
independent
happen
independently
on
every
workspace
forgets.
The
part
where
there's
a
single
server
serving
and
workspaces
right.
E
Right
something
would
but
again,
I
think
it
it
again.
You
know
if
I
understand
the
the
kcp
kind
of
usage
scenario
right.
You
would
really
want
the
the
the
concurrency
limit
of
a
workspace
to
be
a
user
visible
thing
right,
you're
going
to.
E
Page
some
way
right,
you
sign
up
to
pay
this
much.
You
get
that
many.
You
know
seats
of
the
currency
limit,
so
there's
going
to
be
somebody,
that's
engineering,
you
know
workspaces
per
shard
right
and
I
think
part
of
that
job
will.
Probably
it
may
be
this
simple
right,
there's
some
kind
of
configuration
that
goes
into
running
a
kcp
server
and
it
it's
going
to
include
you
know
some
kind
of
a
plan
for
limited
number
on
workspaces
per
server,
and
so
the
server
gets
configured
with
the
concurrency
limit
per
workspace.
E
You
know
and
and
that's
the
the
number
that
the
devs
or
operators
choose
for
that
is
based
on
this.
It's
part
of
this
engineering
of
workspaces
per
server,
yeah.
A
I
could
see
such
a
demo
basically
for
the
prototype
that
you
annotate
this
limit
on
cluster
workspaces,
some
mechanism
in
the
background,
configures,
p
and
f,
and
then
we
can
see
that
a
noisy
neighbor
will
not
impact
you
like.
If
you
have
booked
a
hundred
seats
per
whatever
unit
of
time.
You
will
get
some
right,
something
like
that.
Even
if
somebody's.
E
E
Right
and
again,
if
the
you
know,
concurrency
limit
per
workspace
is
a
constant
you,
don't
even
you
know,
need
it
to
appear
explicitly
on
the
workspace.
It's
just
a
constant
yeah.
We
can
it's.
A
H
H
G
H
Like
something
that's
charged
separately,
like
oh.
C
H
A
Quota,
so
how
how
we
do
billing
at
the
end,
it's
a
different
topic,
but
I
think
the
service
provider
will
pay
as
well
the
same
thing
and
he
will
just
gives
the
cost
to
the
users
using
the
service
in
some
way
buy
a
billing
system
whatever.
But
yes
I
mean
they
are
also
part
of
the
game.
Here.
That's
totally
true.
H
A
Yeah
looking
at
the
time
I
mean
this
is
super
interesting
and
I
think
there
are
a
few
parties
here
who
would
like
to
dive
into
that
more
mike.
Are
you
able
to
organize
one
of
those
design
sessions
this
week
or
early
next
week.
E
A
Maybe
maybe
you
see
the
dock
which
is
not
linked,
but
this
one
here.
A
So
if
it's
not
there
yet
add
a
section
about
p
and
f
people,
everybody
who
spoke
up
here
is
interested
just
put
your
name
behind,
and
then
we
can
schedule
a
meeting
like
one
hour
where
we
can
go
deep
into
that
and
try
to
scope
a
work
item
in
epic
for
the
prototype
and
the
meeting
itself
is
totally
open.
We
can
organize
it
in
any
way
we
like,
like.
We
just
did
with
discussion
or
anything
you
want.
Let's
say:
does
this
find
okay,
sound,
okay,.
E
Let's
see
I'm
looking
to
this
doc
to
understand
it,
so
I'm
looking
so,
let's
see
there's
this
doc.
That
was
point.
The
last
point
I
was
shared
is
this
kcp
work
packages
thing.
A
A
E
A
B
Yeah
perfect
segway
for
this,
so
let's
talk
a
little
bit
about
how
we
organize
for
folks
that
are
new
and
what
the
expectations
are
for
scoping.
A
milestone.
First,
like
stefan
was
saying,
is
prior
to
the
milestone
start.
We
brainstorm
topics
for
the
milestone
in
our
work
packages
document
here.
These
are
just
high
level
items
that
we
try
to
align
with
either
the
next
value
proposition.
B
In
the
first
week
of
the
milestone,
we
asked
that
we
hold
design
discussions
on
those
with
the
invite
going
out
in
the
public
forum
for
folks
to
join
and
the
output
of
those
should
be
an
epic
level
github
issue
with
task
breakdowns
that
clearly
define
what
we
think
we
can
commit
to
in
the
current
milestone
and
items
that
may
need
to
track
in
other
milestones,
so
that
we
have
a
clear
scope
on
that.
So
that's
where
we
are
right
now.
So
what
we're
looking
for
today
is
that
we
have
ownership
for
high-level
topics.
B
Anything
that
does
not
have
ownership
will
move
out
of
the
milestone,
and
then
we
ask
that
those
folks
drive
the
design
discussions
in
public
and
output.
The
actual
github
issues
from
there
doesn't
mean
that
the
owner
has
to
do
all
the
work,
but
it
does
mean
that
they're
responsible
for
driving
the
conversation
and
scoping
for
it.
B
So
that's
where
we
stand
today
in
the
next
community
call
we'd
like
to
go
over
the
output
of
those
discussions,
so
that
we
all
kind
of
have
a
good
idea
of
what
we're
trying
to
achieve
in
this
milestone
and
then
anything
that
does
not
have
an
assignee
in
our
github
issue
list
will
kick
out
and
then
add
people
free
up
within
the
current
milestone.
We
can
pull
things
back
in,
but
we
want
to
set
a
good
observable
expectation
of
what
we
think
we're
committing
to
at
the
beginning.
B
A
So
I
just
want
to
show
one
of
those
epics:
it's
a
multi-release
one,
so
it's
a
big
one.
This
is,
or
this
should
be,
output
of
such
a
discussion
such
an
epic,
which
hopefully
has
demo
objectives.
This
doesn't
for.
I
don't
know
which
reasons
I
mean
this
one,
this
one's
more
like
building
an
sdk.
So
oh
I
see,
but
what
is
it?
Super
important
is
basically
a
line
like
that.
That's
the
scoping
part
so
try
to
scope
it
down,
identify
what
is
crucial
for
the
milestone.
A
What
are
the
most
important
things
like
look
on
the
calendar?
They
are
like
three
weeks
or
a
bit
more
than
three
weeks
from
now,
so
try
to
find
steps
which
get
us
to
the
goal
to
something
of
value,
but
I
mean
have
items
which
go
beyond
that's
all
fine,
but
try
to
make
this
line
draw
this
line.
This
is
a
task.
The
end
of
the
main
task
of
this
meeting
have
an
understanding
in
the
small
team
of
people
where
this
line
is
and
what
the
steps
are
towards.
It.
A
B
A
A
A
There
was
a
discussion
a
few
days
ago,
basically
to
scope
how
placement
should
work
and
what
we
came
up
with
placement
and
locations,
and
we
concluded
that
it
looks
like
a
good
axiom
that
locations
give
you
I
mean
they
are
backed
by
clusters,
but
within
a
location,
workloads
can
move
around
and
they
have
consistent,
networking
and
storage
all
the
time
which
means,
for
example,
a
location
cannot
be
spread
over
cloud
providers.
So
location
is
pure
cloud
provider
because
otherwise
storage,
for
example.
It's
not
seamless
right.
A
A
But
the
question
is:
can
we
make
that
happen,
because
this
is
crucial
for
the
value
proposition
of
tmc
that
you
can
move
around
like
when
one
cluster
goes
down,
maybe
not
by
an
accident
by
maybe
by
eviction
and
draining,
and
your
workload
moves
over
and
this
shouldn't
be
noticeable
from
outside?
So
you
need
something
like
a
mesh
over
those
clusters.
A
G
A
Awesome
right-
and
this
is
the
sources
I
mean
this-
is
just
the
logo.
I've
chosen,
I
added
you-
can
see
readme
here,
which
has
the
variance
so
more
depending
on
context.
We
can
use
that's
the
proposal,
I
did.
The
sources
are
in
there
in
the
pr.
So
if
anybody
wants
to
take
them
and
make
it
more
awesome,
please
go
ahead.
K
Hey,
can
you
guys
hear
me
now?
Yes,
okay,
so
the
previous
talk,
I
think
about
you,
know
getting
transparent,
multicultural
working
for
I.
I
think
it
should
be
possible
to
get
it
working
for
these
services
right,
maybe
not
part
of
pi
communication,
at
least
for
pod
t
service
communication.
I
think
we
should
be
able
to
get
that
working
across
clusters
for
a
location,
so
we
got
a
plc.
That's
we're
starting
for
that.
K
I
do
worry
about
this
notion
of
a
location
only
encompassing
a
single
cloud
right,
just
because,
like
if
your
service
in
your
app
is
not
using
pvs
or
anything
like
that,
like
maybe
you
do
want
to
define
a
location
being
over
multiple
clouds,
because
you
want
your
servers
to
be
able
to
move
between
clouds.
You're.
C
A
The
idea
here
is
basically
a
location
is
what
a
cluster
has
been
in
the
past.
A
cluster
in
the
past
and
cube
has
nodes
and
imagine
all
clusters
in
a
location.
Every
of
those
have
nodes
right
and
the
unit
of
the
nodes
is
basically
what
this
location
represents.
So
it's
like
a
meta
cluster
thing
and
between
nodes
you
can
also
move
right.
A
workload
can
move.
Of
course
there
are
resolutions,
but
in
general
it's
not
sticky
to
a
node
nodes
are
more
or
less
uniform
in
a
cluster
same
idea,.
A
A
K
So
what
is
the
difference,
then
the
the
exact
difference?
If,
if
an
app
can
be
on
multiple
locations,
what
is
it
that
are
location
value,
just
a
grouping?
Because
the
scheduling.
A
E
Stefan,
I'm
surprising
your
answer.
I
was
expecting
to
hear
that
the
locations
are
visible
to
the
user.
So
if
I.
C
E
A
K
C
I
think
it
depends
on
stuff
we
haven't
implemented
yet
so
getting
requirements.
User
stories
use
cases
will
help
us
to
deliver
functionality
like
that.
If,
if
you
all
need
it,
we
don't
have
it
right.
Now
we
have
some
explorations
around
taking
a
single
deployment
that
is
created
in
a
namespace
in
a
workspace
and
replicating
that
to
multiple
sync
targets
or
workload
clusters
like
actual
clusters,
but
we
haven't
expanded
that
to
do
replicating
across
locations
to
my
knowledge,
so
this
is
still
exploratory
and
like
getting
concrete
use.
A
So,
if
you're
interested,
if
you
can
can
contribute,
works,
use
cases
where
even
actual
design
work,
api
work
joins
the
conversations
there,
so
it's
they
will
be
meeting
in
the
next
week.
Everybody's
welcome.
A
J
Staphon,
do
I
understand
the
constraints
location
correctly,
that
if
you
have
a
workload
that
is
assigned
to
a
location
that
it
can
move
freely
within
the
compute
that
makes
up
that
location
with
essentially
their
downtime,
because
it's
more
or
less
homogenous.
But
if
you
move
among
location
boundaries,
then
that's
no
longer
true.
Yeah.
A
I
mean
this
is
this
is
one
I
call
it
an
axiom.
It's
a
proposal
for
an
axiom
just
to
structure
the
problem
domain
we
have
here.
Of
course
we
can
have
total
diversity
within
a
location,
but
this
makes
the
problem
harder.
So
the
proposal
is
to
have
this
restriction
and
have
more
than
one
location.
If
you
cannot
fulfill
the
action.
A
C
Yeah
just
to
follow
up
on
your
no
downtime
question
chris,
like
there's
nothing
right
now
or
I
should
say,
we
can't
guarantee
no
downtime.
If
you
don't
set
up
things
correctly,
so
I
don't
want
folks
to
hear
oh
well
clusters
in
a
location
guarantee
no
downtime,
that's
not
necessarily
the
case.
We
can
help
you
achieve
zero
downtime,
but
it
requires
some
a
lot
of
upfront
planning,
yeah.
A
A
Sorry
yeah
in
nodes
in
cube.
If
you
have
notes
there,
you
want
an
sdn
right,
so
you
want
a
transparent
networking.
If
you
don't
have
that,
you
can
still
create
nodes,
but
things
won't
work
and
the
same
thing
here
you
have
to
fulfill
those
requirements
via
some.
I
know
service
mesh
thing.
I
don't
like
the
word
because
it
sounds
big.
I
hope
this
is
much
smaller,
but
you
have
to
install
certain
things
to
make
those
clusters
compatible
and
work
together.
E
Yes,
I
was
just
going
to
say
right:
can
I
follow
up
on
what
andy
was
saying
right,
or
I
think
andy
is
saying,
don't
talk
about
it
in
terms
of
no
downtime?
I
think
that
the
critical
it
seems
to
me
likely
the
critical
concept
is:
is
user
visible
or
not
right?
The
user
has
managed
what
goes
from
what
goes
in
what
location
the
we
leave
it
to
the
tmc
to
manage
under
the
covers.
E
The
house.
Stuff
is
moved
around
within
a
location,
placed
and
moved
around
within
a
location,
and
there
may
be
some
small
speed
bumps.
We
don't
want
them
to
be
very
large
and
that's
kind
of
the.
The
idea
is
that
right.
J
E
I
think
it's
not
about
buying
you,
it's
just
about
a
feasibility
right.
We
can't
I
get.
I
mean,
maybe
it's
a
matter
of
just
how
big
is
the
speed
bump
right,
but
the
storage
example
is
is
illustrated
right.
We
could
imagine
automated
copying
of
storage
from
one
cloud
to
another.
It
was
to
remain
the
case.
You
know
if
it's
read,
write
storage
that
it's
writable
in
only
one
cloud,
so
it's
in
only
one
location
at
a
time.
H
And
by
the
way,
this
problem
of
workloads
getting
stuck
to
like,
let's
say,
a
cloud
with
tvs,
it's
more
fine
grain
than
that
workloads
could
get
stuck
to
clusters,
because
two
clusters
in
a
single
data
center
could
be
different
enough.
That
you
know
workloads.
C
H
A
E
Yeah,
I
also
hire
them.
I'm
not
sure,
follow
the
example
right
I
mean
like
first
off
clouds,
don't
even
expose
data
centers
right,
they
expose
availability
zones
in
regions
typically
and
right
and
each
one
of
those
is
in
one
particular
country.
So
you
know
there
is
say
gdpr
or
not
it's
it's!
It's
not
like.
There's
a
division
within
one
region
right.
E
A
A
People
can
put
their
input
there
and
the
other
thing
is
the
meeting
so
the
meeting
about
the
design,
so
I
would
propose
to
move
that
to
the
design
meeting.
This
is
the
purpose
exactly
of
this
meeting.
So
it's
great
to
hear
to
hear
the
discussion,
let's
move
it
to
the
meeting
and
then
we
can
spend
the
hour
or
more
time
as
much
as
we
want
to
continue
that
super
discussion.
But
I
think
we
have
to
look
on
the
clock
at
the
moment
so
mike
and
who
was
it?
A
E
I
would
like
to,
but
I
really
could
easily
promise
too
much
here.
I
need
to
be
careful,
I'm
not
that's
not
for
too
much.
A
B
In
terms
of
timing,
we're
hoping
to
have
those
to
be
discussable
in
the
next
community
call
and
ideally
that
people
can
start
developing
on
these,
probably
on
monday.
So
if
we
can
get
design
work
out
in
the
next
couple
of
days,
if
you
can
that's
fine,
it
doesn't
mean
we
need
to
rush
it.
We
need
to
get
it
right
first,
but
that's
that's
kind
of
the
target
that
we
would
have
is
the
rest
of
the
month
after
this
week
for
development.
A
So
I'm
looking
forward
to
great
design
discussions
invitations
for
them.
So
if
there's
no
other
topic,
I
would
move
on
to
the
usual
tasks
of
issues.
New
issues
points
is
okay,
don't
worry
all
right,
so.
A
Incoming
issues,
so
you
routine
all
right,
so
there
are
not
so
many
actually,
so
we
do
good
working
grooming.
Let's
start
with
the
first
one
delegate
to
virtual
workspace
readiness
checks.
That's
david
right
here.
C
Yeah
and
just
as
a
reminder
trying
to
keep
the
discussion
on
these
to
a
minimum,
it's
more
about
just
deciding
the
milestone
yeah.
Yes,
sorry.
F
Sure
I'm
there
in
fact
I
fixed
that
this
morning
it
was
a
follow-up
issue
that
was
that
popped
up,
internet
tweaks
and
the
peer
is
approved.
And
now
you
know,
checks
are
okay,
so
it
should
be
merged
today,
all
right,
so
I.
A
Move
it
to
zero
six,
even
though
it's
in
the
blocker,
maybe
okay,
if
you
can
link
zpr,
it's
fine
sure,
sean,
add
acceptance
of
permission,
api
to
appear
binding.
G
A
A
C
This
is
for
permissions
and
the
claims
yeah
and
he's
not
on
the
call
right
now
that
I
see.
C
Like
one
scope,
scope,
yeah,
I
think
your
suggestion
to
have
the
the
cut
line
for
what's
must
have
versus
can
come
later.
We
should
do
yeah,
that's
cool,
okay,
I'll
work
with
him
on
that.
A
E
Sure
it's
really
simple.
I
tried
to
create
a
child
workspace
named
root
and
it
got
an
error
message
that
you
know
it
comes
from
somewhere.
It's
nested
right,
it's
it's
grabbed.
It
reflects
several
layers
of
it's
coming
from
somewhere
in
the
code
that
I
don't
know
you
know
a
user
is
not
going
to
understand
right.
I
think
the
the
conceptually
right,
it's
pretty
simple,
you
know
the
name
root
is
reserved
for
the
actual
root.
A
Yeah
there's
a
logical
on
not
in
the
in
the
expression,
open
api,
and
this
gives
you
that
output,
which
is
not
helpful,
so
I
can
give
pointers
if
anybody
wants
to
look
into
admission.
This
can
be
done.
It's
a
good
first
issue.
If
you
want
to
learn
about
admission,
so
we
need
another
check
with
a
human,
understandable
level
right.
That's
what
you
want,
what
you
mean
technically,
it's
very
legit,
but
it's
just
not
helpful.
A
A
A
All
right
this
was
my
wish
to
have.
We
have
pro
in
the
work,
so
steve
is
doing
great
work
to
move
us
to
pro
and
get
rid
of
frustrations
of
the
work,
the
workflows
of
github,
I
think
we
are
near
so
maybe
steve
can
explain
in
a
second.
This
one
is
about
the
document,
something
which
points
to
this
is
openshift
release
paper,
where
we
put
stuff
now
yeah,
something
like
that.
The
link.
G
Yeah
I
mean
the
update
update's
pretty
minor.
Basically,
we
just
have
jobs
now
running
via
prowl,
on
a
cube
cluster
that
mirror
what
we
were
doing
in
the
github
actions
sans
won.
I
would
hope
that
we.
G
I
don't
know,
I
guess
it's
kind
of
a
double-edged
sword.
I
would
hope
that
we
are
able
to
give
enough
juice
and
like
computational
power
to
these
jobs
such
that
they
run
faster
and
we
see
fewer
of
these
like
pathological
flakes.
It's
definitely
hiding
some
bugs.
We
really
have
in
the
product,
but
at
the
same
time,
like
I'm,
not
sure
that
having
ci
flake
out
85
of
the
time
is
a
useful
signal
to
anybody.
So
that's
the
hope
anyway.
G
G
G
A
To
solve
this
question
and
all
right
so
anyway,
good
work,
great
work,
I
like
it.
Next
one
still
have
four
minutes,
or
so
that's
a
flake
right,
oh
yeah,
that
one
so
there's
a
creation
issue.
I
think
andy.
You
have
ideas.
C
A
C
I
saw
this
locally
and
just
ignored
it
because
it
wasn't
bothering
me,
but
I
don't
know
anything
about
this.
It's
even
another
one.
I
think.
A
C
Two
halves
to
it:
half
of
it's
in
the
environment
variable
fixes
in
this
is
about
volume,
mounts.
A
Missing
into
and
test
for,
syncing
connection
to
oh
yeah,
this
is
we
have
finalizers
and
we
touched
the
topic
earlier
today
about
the
life
cycle
of
work
notes.
When
the
cluster
goes
down
and
there
is
code
about
finalizers
in
place,
I
think
it's
partly
under
future
gate.
Your
game
will
know
more.
Yes,.
I
Yes,
the
finalizers
are
still
feature
gate.
It's
part
of
the
advanced
scheduling,
pr,
I'm
working
right
now
on
on
moving
the
finalizers,
the
kubernetes
ones
and
the
virtual
ones
outside
of
the
feature
gate
by
adding
the
proper
end-to-end
test.
So
it
should
be.
I
go
tomorrow,
so
it's
in
progress,
that's
cool,
yeah
yeah,
maybe.
A
A
last
one
for
today
that
once
in
kcp
cube,
conflict
workloads
is
this.
I
think.
C
C
A
C
Yeah
I
mean
I
think
we
could
have
like
a
collection
of
gr
like
group
resources
and
paths
to
a
pod
spec
in
them,
and
then
you
could
just
generically.
Have
this
thing
apply
to
a
bunch
makes
sense.
So
if
anybody.