►
From YouTube: KCP-Edge Community Meeting, February 9, 2023
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
Hello
everybody
good
afternoon,
good
evening
good
morning
today
is
Thursday
February,
9th
2023
back
to
the
next
installment
of
the
kcp
edge
community
meeting.
My
name
is
Andy.
We're
going
to
go
through
a
few
General
items.
Discussion
points
today,
but
first
I'd
like
to
read
off
our
contributed
code
of
conduct
as
contributors
and
maintainers
in
the
cncf
community
and
in
the
interest
of
fostering
an
open
and
welcoming
committee
Community.
A
We
pledge
to
respect
all
people
who
contribute
through
reporting
issues,
posting
feature,
requests,
updating,
documentation,
submitting
pull
requests
or
patches
and
other
activities
we're
committed
to
making
participation
in
the
cncf
community
harassment
free
experience
for
everyone.
So
basically
it
just
means,
please
everyone
be
nice
to
each
other
all
right!
Thank
you
all
for
joining
today
it
looks
like
we
have
a
few
agenda
items
on
here.
A
Mike
has
just
added
one
or
two
all
right
so
wanted
to
go
over
really
quickly.
With
all
of
you,
there's
been
some
updates
this
week,
we've
got
quite
a
few
events
that
we're
tracking
for
2023
to
participate
in,
and
we've
also
started
doing
some
awareness
in
the
community
about
what
what
it
is
we're
working
on.
What
we've
worked
on
in
the
past
and
trying
to
publish
on
that
so
in
insofar
as
we've
created
a
a
Blog
series
which
is
and
its
own
dedicated
medium
category,
I'll
go
ahead
and
drop.
A
Just
looking
for
my
Safari
here,
I
don't
see
there,
it
is
okay,
so
we
started
up
a
a
medium
area
where
we
can
house
a
lot
of
the
blogging
and
information
and
awareness
that
we're
we're
building
today,
one
in
particular
of
of
the
subcategories
is
kcp.
A
I
went
ahead
and
built
a
and
published
a
blog
entry
earlier
this
week,
and
it's
more
or
less
a
Masthead
and
it'll
it'll
serve
as
a
link
and
a
router
to
other
Communications
and
documents
that
will
blog
entries
will
be
posting
just
to
refer
real
quickly.
You'll
see
things
like
these
references
show
up
inside
this
blog
over
the
course
of
time.
A
A
And
so
far
as
our
upcoming
events
we
are,
we
are
responding
to
a
cfp
for
the
IEEE
Edge
Computing
series
that
is
taking
place,
I
believe
in
early
May
we're
also
going
to
be
contributing
to
get
Ops.
Con
Jun
has
been
kind
enough
to
respond
to
a
cfp.
For
that
we're
waiting
for
approvals.
A
We
have
our
eyes
on
platform.
Con
and
kubecon
cfps
for
clue.
Count
have
not
been
announced
yet
and
we're
still
trying
to
figure
out
if
there's
anything
any
there
for
platform
con
that
we
can
work
on
so
I'll.
Add
those
events
in
here
too.
A
A
Okay,
let's
move
on
to
the
next
topic:
Mike,
would
you
want
to
lead
us
through
the
where
you
are
today
or
the
the
q1
POC.
B
Yeah,
so
there
are
some
recent
conversations
that
have
not
yet
been
reflected
in
the
pr,
but.
B
Than
that
you
know
the
there
is
the
pr
that's
been
there
for
a
while,
but
there
are
a
couple
of
things
that
still
need
to
be
dealt
with.
B
B
We'll
just
do
something
interim
to
get
the
get.
You
know
something
running
so
that
we
can
focus
on
the
parts
that
we
are
focusing
on.
So
that's
that's
one
thing.
The
other
thing
is
much
bigger
really,
and
it's
really
a
big
oops
I've
come
to
realize
it
coming
at
it
from
a
couple
different
directions.
You
know
we
we
have
talked
about
wanting
to
support
a
variety
of
use.
B
Cases
such
as
maximum
visual
inspection
is
one
example,
and-
and
we
have
others
that
really
require
us
to
transport
cluster,
scoped
or
non-namespaced
differently,
saying
the
same
thing:
resources
from
Center
to
Edge,
which
transparent
multi-cluster
does
not,
and
in
thinking
about
that
I
came
up
against
the
fact
that,
well,
you
know
some
of
these
resources
right.
You
know
kind
of,
broadly
speaking,
we've
been
thinking
and
in
the
sort
of
the
points
of
the
POC.
B
It
calls
out
the
idea
that
we're
using
the
kcp
workspace
as
a
a
denatured
API
server
as
a
container
of
workload.
But
the
problem
is
some
of
the
object.
Types
are
are
interpreted
by
the
API
server
itself,
they're,
not
interpreted
by
external
controllers.
They
modify
the
behavior
of
the
API
server,
so
they
can't
be
denatured.
B
The
fact
that
there
are
these
objects
that
modify
the
behavior
of
that
API
server.
They
don't
have
to
be
transported
to
the
compute
cluster.
They
remain
in
the
origin.
Workspace
modifying
the
behavior
of
that
API
server.
B
These
are
right
kind
of
two
different
ways
of
coming
at
the
same
problem,
which
is
that
for
Edge
we
do
want
self-sufficient
Edge
clusters.
We
do
need
fully
denatured
containers,
and
you
know
it's
just
a
realization
that
actually
a
kcp
workspace
is
not
a
fully
denatured,
API
server.
Another
way
of
kind
of
expressing
this
is,
as
you
know,
kind
of
a
general
engineering
principle
right.
B
We
know
the
idea
of
separating
data
plane
and
control
plane,
but
in
the
kubernetes
API
servers
they
haven't
done
that
there
are
in,
if
you
think
of
it,
as
you
know,
kind
of
a
generic
API
server.
But
there's
also,
you
can
put
workload
objects
in
it,
but
you
can
also
put
objects
in
it
that
modify
the
behavior
of
API
server
itself.
So
this
one
server
holds
both
control.
Plane
objects
that
modify
the
behavior
of
the
control
plane,
as
well
as
data
plane,
objects
that
describe
the
workload
that
the
control
plane
is
trying
to
control.
B
D
A
clarification
for
for
me
that,
let's
see
so
you
think
it's
a
technical
issue
that
will
prevent,
because
originally
before
there
was
some
kind
of
filtering
process
that
was
preventing
the
transport
of
these
non-names-based
object.
But
now
your
your
understanding
is
that
it's
a
really
technical
issue
that
may
not
be
easy
to
solve.
B
It
is
a
technical
issue
that
will
not
be
easy
to
solve.
I
think
you
know
kind
of
I
expressed
three
ways
of
coming
at
it.
Perhaps
the
most
fundamental
and
clear
is
that
in
kubernetes,
API
Machinery
they
mix
together
in
one
API
server.
Both
objects
that
modify
the
behavior
of
that
API
server
and
objects
that
describe
some
workload
because
it's
kind
of
you
know
think
of
the
API
server
and
it's
often
called
right.
B
The
the
KC
people
call
it
on
a
control,
plane,
I
think
it's
less
than
a
control
plane,
but
it's
part
of
a
control
plane.
But
the
point
is,
you
know:
in
general
engineering
we
often
talk
about
a
separation
between
control
planning
data
plane,
but
in
kubernetes
API
servers
you
have
both
kinds
of
objects
to
the
same
server.
B
Well,
I
mean
maybe
you
know
in
other
uses
of
kubernetes
API
Machinery,
it's
not
so
much
a
problem,
for
example
in
transparent
multi-cluster.
It's
not
a
problem,
because
the
containers
are
connected
back
to
the
origin,
API
server
and
and
so
that,
coupled
with
the
fact
that
most
of
the
objects
that
no
that
that
gets,
coupled
with
the
fact
that
the
Sinker
is
programmed
to
only
trans,
to
not
transport.
These
objects
that
modify
the
behavior
of
the
API
server
because
it
doesn't
need
to,
or
maybe
it
modifies
them
I'm
not
entirely
totally
familiar.
B
Yeah
so,
but
the
most
important
thing
is
mainly
these
objects
that
modify
the
behavior
of
the
API
server.
They
remain
back
in
the
origin,
API
server,
the
workload
containers
get
connected
back
to
the
origin,
API
server,
so
these
objects
are
doing
their
job
without
being
transported
from
origin,
API
server
to
or
workload
cluster.
Let
me
stop
talking
and
let
let's
go
on
David
here.
B
F
F
B
Right
so
examples
of
things
that
mod
obviously
modify
the
behavior
of
the
API
server
are
back
custom
resource
definitions,
the
admission
control,
plugins,
the
API
service
objects,
the
program
delegation.
F
What
what
do
you
mean?
I,
I,
just
wonder
so,
I,
don't
completely
understand
why
it's
a
problem
for
this
use
case,
because
with
permissions
you
you
can
solve
a
lot
of
those
issues.
I
guess,
on
the
other
hand,
in
kcp
we
would
be
much
more
flexible
to
maybe
completely
hide
those
or
makes
them
unavailable.
So
imagine
you
I
mean
API
bindings.
They
basically
inject
behavior
from
outside
right
there
you
don't
have
control,
they
are
not
as
powerful
as
cids
cids
are
inside
right.
F
E
Well,
you
mentioned,
you
know
API
server
crds,
you
know
you
mentioned
airbag
and
obviously
can
we
say
that
probably
we
have
to
you
know
categorize
the
various
cases
of
cluster-wide
resources
that
you
would
need
in
your
case
that
you
would
need
to
be.
You
know,
moved
to
the
physical
cluster
that
has
to.
B
F
F
E
But
the
the
I
mean
isn't
I
mean,
am
I
right,
saying
that
the
problem
you
you
mentioned
here
is
that
you
know.
For
example,
you
have
a
workload
on
your
physical
cluster
and
maybe
your
workload
needs
some
of
the
to
work
correctly.
Some
other
objects
that
would
should
be
also
on
the
physical
cluster.
In
order
to
modify
the
the
way
your
workload
you,
we
will
run.
A
Yeah
David
so,
for
instance,
for
mvi,
when
we
install
that
we
install
an
operator
and
the
operator
can
go
in
the
same
namespace
as
mvi
itself,
but
the
operator
that
operates
mvi
could
go
in
a
different
operator.
It
also
needs
cluster
roll
bindings
as
well.
E
Yes,
which
means
that,
if
you
need
to
work
to
continue
working
in
a
disconnected
way
without
having
access
to
to
kcp
when
you're
stuck
because
the
objects,
the
other
objects
that
modify
or
you
know,
Drive
the
the
overall
Behavior
they
are
not
on
the
physical
cluster,
so
they
are
not
available
to
to
the
main
controller.
It's
it's
your
problem,
isn't
it
but.
B
E
So
mainly
does
it
mean
that
you
know
if
we
would
go
on
the
edge
and
HMC
side
if
we
would
go
with
the
ID
that
we
don't
point
back
workloads
to
kcp
that
that
was
what
we
discussed
then
that
seems
to
mean
that
we
have
to
also
think
I'm,
not
saying
that
we
should
do
that.
But
that
way
you
have
to
think
all
the
other
objects
be
their
namespaced
or
cluster
white
that
are
required
by
this
workload.
B
Mainly
right,
yes,
that's
one
way
of
looking
at
it
and
by
the
way,
right
to
be
clear
here
we
don't
know
what
the
workload
is.
We
don't
know
what
has
to
be
transported
right.
This
all
has
to
be
programmed
by
users
of
edge
right
us
and
we
we
can't
decide
all
this
stuff
at
development
time.
It
has
to
be
in
some
sense.
You
know
programmable
through
API
objects,.
E
By
the
way,
I
mean
purely
technically
thinking
across
the
white
object
is
something
that
is
not
impossible.
It's
already,
you
know
partly
implemented
for
a
very
small
subset
of
of
resources
like
PVS.
In
the
context
of
you
know,
storage
move.
B
C
B
Really
this
one
of
the
ways
of
looking
at
this
is
there's
a
conflict.
If
we
say
that
the
kcp
workspace
is
a
container
for
workload
right,
the
problem
is
it's
not
a
fully
denatured
container
we've
put
stuff
in
if
there's
something
some
of
some
kinds
of
objects
right,
if
we
put
them
in
the
workspace,
they
don't
just
modify
what
happens
at
the
edge.
They
also
modify
what
happens
in
that
workspace.
B
All
the
ones
with
modify
server
Behavior
right.
We
just
talked
about
that
right,
the
r
back,
yeah
D's
themselves,
the
you
know
the
the
plugins
for
admission
control.
You.
D
B
F
The
edge
but
make
like
mention
so
we
have
bindings
in
kcpu
I'd,
say
and
we
use
them
for
pretty
cool
low
level
personality
like
everything
else
you're
just
not
in
apis
kcpio,
is
basically
a
binding.
There
are
some
resources
which
are
from
cube
right,
crds,
all
the
airbag
objects.
Api
servers
doesn't
exist,
I
think,
but
basically
those
if
we
thought
of
them
as
yet
another
binding.
So
imagine
you
could
create
the
workspace
which
is
completely
empty,
or
maybe
it
just
has
bindings
nothing.
F
This
would
solve
your
problem
because
I
think,
then
you
can
import
a
different
kind,
so
it
takes
it
takes
example
of
cids.
You
would
add
a
binding
to
something
which
looks
like
a
CLG
but
doesn't
have
Behavior.
That's
what
you
want
right
if
you
want
to
container
only
without
Behavior,
without
the
controllers
behind
that
would
give
it
well.
B
What
I
want
you
know?
What
we're
trying
to
do,
I
think,
is
that
the
reason
that
we
liked
the
idea
of
a
denatured,
API
server
as
the
container
is
that,
for
you
know
all
the
stuff,
that's
been
shifted
left.
If
you
know
the
term
shift
left
right
there,
people
have
got
a
lot
of
stuff,
that's
clients
of
API
servers
that
is
about.
You,
know
developing
and
delivering
objects
into
API
servers
right,
and
you
know.
B
So
the
problem
here
part
of
the
problem
is
you
know
to
in
order
to
pursue
that
program.
All
the
stuff
that's
been
shifted
left
needs
to
deal
with
exactly
the
regular
API
they
these
deal
exactly
with
real
custom
resource
definitions,
real
rbec
objects
and
so
on.
F
B
B
F
B
F
E
Yes,
but
how
does
it
solve
the
fact
that,
as
soon
as
even
through
bindings,
you
add
those
okay,
the
fact
that
through
bindings,
you
add
those
objects,
even
if
they
have?
You
know
the
same
API,
Group
name.
E
It's
a
different
identity,
so
they
would
not
be
checking
unicorn
by
the
default.
You
know
the
delegate
authorizer
all
these
things
for.
F
E
Okay,
you
know
you
mean
the
the
standard
cubes
here.
These
CID
controllers
would
not
see
them,
because
this
here,
the
the
underlying
crd
is
not
the
same
right
yeah.
Yes,
this
makes
sense.
B
E
B
If
you
take
these
objects
which
normally
modify
server
behavior
and
you
make
them
not
modify
server
Behavior,
that
begs
a
couple
of
questions.
We
do
still
need
server
Behavior.
It
does
still
need
to
be
controllable.
Somehow
and
crds
in
particular,
make
it
possible
to
create
the
CRS.
If
you
denature
the
crds,
how
do
you
make
the
corresponding
CRS?
B
B
Right
so
in
part,
one
part
of
the
answer
may
be
that
in
some
sense
the
behavior
is
innocuous
or
desired.
So,
even
though
the
main
goal
is
to
get
the
behavior
in
the
edge,
it's
either
I,
don't
care
or
a
positive
do
want.
We
also
do
in
some
cases,
want
the
behavior
in
the
center
or
right
we
so
for
in
the
example
of
crds.
We
do
want
the
ability
to
create
the
CRS
in
the
center,
as
well
as
at
the
edge.
E
B
C
B
E
Because,
on
the
on
the
physical
cluster,
you
you
don't
cope
with
bindings
at
all,
you
just
the
Sinker,
just
syncs.
What
is
exposed
by
kcp
by
the
virtual
workspace,
so
I
mean
as
soon
as
it's
as
it's
on
the
physical
cluster.
There's
no
more
question
about
bindings.
If
you
brought
Downstream
the
right
object
with
the
right
API
resources,
maybe
a
misunderstanding,
something
but
okay.
D
B
I'm
not
quite
sure
what
you're
saying
we
so
I
think
the
the
problem
or
conflict
I'm
seeing
is
that
we
want
to
enable
users
of
HMC
to
be
able
to
include
in
their
workload
objects
that
modify
server,
Behavior
and
potentially
for
some
of
those
objects.
We
do
not
want
them
to
modify
the
kcp
workspace
behavior
in
the
center.
E
Yeah
but
but
let's
imagine
that
you
would,
you
know
for
at
least
for
the
objects,
the
standard
objects
that
are
not
here
that
are
not
through
API
bindings
for
now
they're
back
and
and
those
imagine
that
there
would
all
be
possibly
available
through
API
bindings,
then
you
would
be
able
at
least
manually
at
first
to
build
your
API
export
in
you
know,
in
some
place
that
defines
a
subset
of
those
resources.
E
You
don't
want
standard,
Cube,
very
Behavior,
to
to
be
triggered
on
and
then
as
soon
as
and
the
other
standard
resources
for
which
you
still
want.
It's
not
Behavior
to
be
triggered.
Then
you
would
not
add
in
the
export.
So
if,
if
it,
if
it's
everything
about
the
type
of
the
results,
then
probably
it
should
it,
it
could
be.
You
know,
managed
by
creating
a
dedicated
API
spot,
which
then,
of
course,
since
it's
API,
you
can
also
automate,
according
to
you
know
higher
level
apis.
Now,
if.
E
B
Buy
them
right,
so
maybe
we
should
just
go
through
them
more,
particularly
rather
than
lump
them
all
into
one
vague
cloud.
So,
let's
start
with
custom
resource
definitions
right.
Those
are
perhaps
the
EVS
case,
because
I
think
those
are
one
of
the
not
just
don't
care,
but
we
positively
want
them
to
modify
the
workspace
Behavior
as
well
as
the
edge
cluster
Behavior.
So
those
are
those
are
actually
not
a
problem
here.
Those
are
kind
of
the
the
easiest
case.
B
Now,
let's
try
the
rbac
objects,
both
cluster
scoped
and
namespace
scoped,
since
they
only
add
to
what's
allowed
in
some
sense,
they
don't
prevent
the
center
from
doing
anything
we
want.
They
only
have
the
downside
of
enabling
things
to
happen
at
the
center
that
we
don't
particularly
care
to
enable
at
the
center.
B
So
if
we
could
and
here's
the
problem
right
in
the
center,
we
do
still
need
our
back
in
the
center
right.
The
problem
is,
we
have
some
R
back
objects
in
the
center.
C
C
E
C
B
E
B
And
you
know
one
one
in
some
sense
solution
would
be
for
all
of
these
object
types
that
modify
server
behavior
and
we
want
to
treat
them
as
workload.
We
could
Define
alternate
versions
right,
or
maybe
we
call
them
denatured
versions
or
workload
versions
right,
and
so
they
would
inherently
be
not
interpreted
in
the
center
and
it
would
be
part
of
the
thinker's
job
to
get
them.
You
know,
transport
them
relate
them
to
their
non-denatured
or
normal
versions
at
the
edge.
B
B
D
B
Is
changing
the
object
type
yeah?
You
could
do
that,
but
it
still
suffers
from
the
disadvantage
that
everything's
been
shifted.
Left
has
to
now.
G
A
Yeah
I
mean
if
you're
already
talking
about
I,
mean
and
I'm
way
out
of
I'm
way
over
my
skis
on
this
one,
but
I'll
try
to
and
put
as
much
as
I
can
about
what
I'm
thinking
is.
If
you've
already
gone
through
the
trouble
of
denaturing.
The
end
point
then
I
think
having
a
customization
that
changes.
The
type
isn't
really
so
far-fetched,
but
that's
just
me
I
mean
I
I'm,
not
you
have
other
principles
you're
trying
to
adhere
to.
E
F
Heck
is
thinking
you
could
also
Imagine
two
views
of
a
workspace
like
the
kcp
native
view,
where
you
see
the
native
objects
with
behavior
and
those
were
coming
from,
which
offers
workloads.
They
are
renamed
like
different
groups
and
the
moment
you
you
look
from
the
other
side
from
the
other
angle.
You
would
see,
but
you
wouldn't
see
those
system
resources,
but
you'd
only
see
those
workload
resources
no.
B
Idea,
yeah,
just
let
me
let
me
try
to
repeat
that
back
to
you
see
if
I
understand
correctly,
so
we
might
say,
for
example,
that
in
the
center
clients
in
the
center
see
in
some
sense,
a
unfiltered
View
and
the
sinkers
see
a
modified
View.
B
So
we
can
take
the
approach
of
having
for
the
objects
that
modify
server
Behavior,
that
we
don't
want
to
modify
the
center
Behavior.
We
have
alternate
group
version
kind
of
rabies,
just
a
label
or
an
annotation.
We
somehow
mark
them
and
no,
it
would
have
to
be
different
group
version
kind
because
we
want
to
denature
them
in
the
center
for
the
ones
that
we
want
denatured
in
the
center.
B
We
have
alternate
object
type,
that
is,
you
know,
uninterpreted
in
the
center,
and
this
view
Maps
them
into
the
interpreted
types
so
that
the
Sinker
puts
The
Interpreter
types
in
the
edge.
F
Yeah
I
was
also
thinking
about
I,
don't
know,
especially
the
natural
view
that
every
client
can
use,
but
has
to
opt
in.
B
F
F
C
This
is
also
some
happy
thinking,
I'm
thinking,
whether
we
can
use
the
aggregation
layer
to
boost
up
another
API
server,
as
well
as
its
own
xcd,
which
serves
as
a
mirror
of
the
main
APS
server
and
for
each
of
our
workspace.
We
have
a
Shadow
Mirror
in
that
aggregated
APS
server,
which
is
dedicated
to
store
the
objects
which
needs
to
be
denatured
in
the
center,
so
that
that
those
data,
those
mirror
API
server.
This
Behavior,
we
don't
care
about
it.
So
just
let
the
the
whatever
product
or
whatever
project,
to
modify
that
behavior.
B
I
have
a
couple
of
concerns
about
that.
First
off:
remember:
we
have
for
some
kinds
of
objects.
We
need
to
make
the
distinction
on
the
instance
level
rather
than
the
type
level,
but
delegation
to
external
servers
is
on
the
basis
of
API
Group.
B
B
I
believe
our
back
is
interpreted
in
the
external
server.
Is
that
right,
yeah.
D
E
Maybe
this
this
transmit
what
what
I
want
wanted
to
propose
just
before,
instead
of
having
an
external
API
server
on
something
more,
why
I
mean?
Well,
we
are
unhacky
thinking.
Why
not
having
two
workspaces?
You
know
you
have,
of
course
the
the
full
option
would
be
to
have
a
view
as
as
Stefan
said,
but
but
you
know
on
very
short
term
solution,
which
would
be
mainly
quite
the
same
in
terms
of
principle.
Just
have
two
workspaces:
the
workspace
hit
by
the
external.
E
You
know,
client
that
wanted
to
push
whole
his
resources,
mainly,
and
probably
we
would
add
a
theory
that
defines
what
is
you
know
what
should
trigger
standard
Behavior?
E
What
should
not
so
the
angels
I
would
put
that
in
a
given
workspace,
but
this
workspace,
but
all
those
objects
would
be
based
on
bindings,
so
it
would
not
trigger
any
Cube
standard
mechanism
and
then
you
would
have
a
controller
that
would
mainly
mirror
that
in
the
Target
workspace
just
another
kcp
workspace,
which
is
the
one
linked
to
thinking
and
when
your
controller
would
do
that,
it
would
take
in
account
the
policy
about.
E
You
know
a
standard
behaviors,
the
the
the
dedicated
object
and
then
it
would
also
create
the
API
export
that
corresponds
to
that,
but
rename
the
group
of
some
of
the
instances
in
order
to
you
know
mirror
them
in
the
second
workspace,
according
to
I
mean
either
to
the
new
group
for
others
that
should
not
not
trigger
standard
Behavior
or
to
the
old
group
for
others
that
for
those
that
should
should
trigger
the
standard,
behavior
and
then
from
this
second
workspace,
you
could
have
just
normal
thinking
of
all
those
resources.
E
B
No
I'm,
not
quite
sure,
I,
follow
you
and
I
haven't
had
time
to
think
through
what
Stefan
lost
said
about
this
other
way
of
using
views,
so
I
I'm,
sorry,
I,
can't
quite
think
as
fast
as
people
are
talking
I'm
going
to
just
have
to
take
it
in
latest
comments
first
and
get
back
to
Stefan
so
for
David.
I'm,
not
quite
sure,
I
understand
that
how's.
How
that
solves
the
problem
for
our
back
objects,
where
you
want,
on
instance,
level
to
decide.
D
B
E
B
B
F
F
B
Okay,
let
me
repeat
that
back
to
you
make
sure
I
understand.
So
the
idea
is,
we
use
a
view
for
so
the
stuff.
That's
shifted
left
uses
a
view
in
which
everything
is
denatured,
and
that
is
just
a
view
and
it
transforms
it
by
basically
injecting
into
the
actual
workspace
for
the
cases
of
things
that
modify
server
Behavior.
It
would
so
that
this
so-called
denatured
view
would
have
objects.
The
regular
object,
types
that
modify
server
Behavior.
B
They
appear
in
the
denatured
view
for
use
by
shifted,
left
stuff
as
the
usual
object
types,
but
they
don't
actually
modify
the
center
workspace.
Behavior
The
View
causes
them
to
be
represented
as
alternate
group
version
resource,
so
that
is
not
interpreted
by
the
the
center
workspace
and
the
other
part
of
the
problem
is
this
the
sinking
to
the
edge?
Somehow
the
the
transport
from
Center
to
Edge
needs
to
converse
to
the
converse:
transform
transform
them
back
into
the
object
types
that
really
do
affect
server
Behavior
at
the
edge.
F
B
All
right,
I
think
I
understand.
Thank
you
all
right,
I
don't
want
to
take
up
the
whole
meaning
my
gosh.
It's
gone
on
very
long.
Maybe
we
should
just
you
know:
we've
had
an
interesting
kind
of
brainstorming
session.
We
maybe
we
can
all
take
a
break
now
and
think
about
it
and
come
back
at
it.
Yeah.
A
Mike
I
wanted
to
ask
you:
is
it
okay
to
share
that
that
punch
list
that
we
came
up
with
in
the
last
few
days
in
Google,
Docs.
B
Yeah,
if
you
think
the
broader
Community
is
interested,
yeah
I
mean
if
someone
else
wants
to
contribute.
That
would
be
great
yes,
but.
B
B
A
The
second
thing
is:
Vivek
is
going
to
give
us
an
overview
of
the
next
item
on
the
agenda:
predictive
maintenance
using
ml
apps,
so
he's
got
some
questions
for
us,
so
I
just
want
to
do
a
quick
one
minute.
You
know
make
everybody
aware
of
this
flash
it
and
then
we'll
get
back.
Let's
see
if
I
can
show
it.
Okay,
so
to
those
of
you
on
the
call
that
have
not
been
so
far
involved
in
it,
we
have
a
POC
where-
and
that
was
some
of
the
discussion.
A
Well,
that
was
all
the
discussion
that
Mike
was
talking
about
in
the
specifics
for
delivering
workloads
that
need
X
higher
privileges
than
what
we
are
accustomed
to
seeing
from
when
we
deliver
a
workload
using
the
Sinker.
But
this
is
the
the
larger
umbrella
project
that
we're
working
on.
This
is
the
proof
of
concept
that
will
show
off
on
March
30th
we're
going
to
try
and
do
the
proof
of
concept
in
the
open,
which
will
be
a
first
for
us.
A
We've
done
these
behind
closed
doors
in
the
past,
and
so
this
is
essentially
some
of
the
parts
that
have
been.
This
is
most
of
the
parts
that
have
been
identified
so
far
as
what
we
want
to
accomplish
so
I'm
going
to
go
ahead
and
share
this
out
if
I
have
the
rights
to
to
kcp
Dev.
If
anybody's
looking,
you
know
for
some
things,
to
contribute
on
we'd
love,
to
have
some
cross-pollination
from
kcp
and
from
anybody
else.
A
That's
on
the
call
I'll
take
it
up
offline
with
David,
Stefan
and
Andy
to
see
if
they
want
to
circulate
this
internally
with
the
kcp
team.
A
G
G
So
my
whole
idea
is
right
now:
I
pursue
a
research
project
based
on
the
predictive
maintenance
and
the
whole
Focus
was
to
implement
the
envelopes
perspective
and
and
in
Stuttgart
I
work
with
Mercedes
and
collaborated
with
this
project
with
the
university
as
well
so-
and
this
is
going
to
be
like
a
open
project
with
the
university
and
right
now,
like
I,
have
the
whole
kubernetes
infrastructure
and
I
also
deal
with
data
orchestration
layers
with
the
yeah
different.
G
You
know,
softwares
like
airflow
and
then
I'm
also
trying
to
get
the
modeling
ml
models
tracking
server.
So
right
now,
I
deal
with
the
predictive
maintenance
use
case
and
I'm
just
reaching
out
here
to
see
if
what
kind
of
a
ml
modeling
strategy
I
can
reach
out
here.
So
that
is
my
main
focus
product
as
well,
but
from
the
infrastructure.
I've
got
everything
ready
so
and
if
someone
has
insights
on
the
ml
modeling
process,
that
would
be
really
helpful.
A
If
I
can
give
some
background,
color
on
this
I
was
someone
someone
had
reached
out
internally
at
IBM
to
see
if
there
was
anything
that
we
were
doing
in
terms
of
projects
centered
around
you
know,
working
on
connecting
with
Edge
devices
and
Edge
locations
having
to
do
specifically
with
things
like
you
know,
robots
that
are
operating
at
the
edge
or
manufacturing
equipment,
industry,
4.0
and
I
said
you
know
there
might
be
a
possibility
of
some
overlap,
not
necessarily
in
the
AIML
space,
but
in
the
distribution
of
the
modeling,
similar
somewhat
similar
to
what
we've
done
for
mvi.
A
So
I
wanted
to
get
Kristoff
sent
Vivek
over
to
have
a
look
at
our
community
and
to
introduce
himself,
and
we
think
it
might
be
interesting
to
pursue
a
little
bit
further.
So
I
wanted
to
introduce
what
he's
working
on
and
I'll
be
so
vivec.
What
I
was
going
to
do
is
I
wanted
to
work
with
you,
I'm
glad
you
came
to
the
meeting.
Thank
you
and
I
wanted
to
see.
I
could
work
a
little
a
little
bit
with
you
offline,
to
take
some
time
to
educate
you
on
what
it
is.
B
The
top
level
response-
let
me
I,
think
I
would
say
you
know
this
intensifies
a
question
that
began
with
our
first
attempts
to
work
with
mvi,
which
is
you
know
how
to
transport
models
between
Center
and
Edge
they're
too
big
to
be
handled
as
cube,
API
objects,
so
the
it's.
We
need
a
different
sort
of
framework
and,
in
fact,
I
think
for
model
transport.
We
shouldn't
even
be
trying
to
invent
there's
already
a
lot
of
precedent
out
there
right.
We
should
be
looking
at
how
to
work
with
existing
interfaces.
B
You
know
maybe
have
some
alternate
implementations,
but
you
know,
there's
exists
a
lot
of
existing
technology
for
producing
and
consuming
models
right,
let's
think
about
what
interfaces
they
use
and
how,
to
you
know,
seamlessly
make
it
work
for
Edge
appropriate
transport.
So
that
means,
for
example,
tolerating
lengthy
disconnection.
So
we
we
need
an
implementations
based
on
store
and
forward.
You
know
not
online
TCP
connections.
A
Yeah-
and
some
of
that
also
is
some
of
the
work
that
we've
been
investigating
with
the
Rendezvous
project
on
the
side,
there
are
some
inter
I
think
there's
some
of
the
information
here
can
be
interleaved
with
that,
but
not
necessarily
so,
but
yes,
I,
agree
with
you,
I
think
at
the
moment
we
can
use
interfaces
instead
of
trying
to
reinvent
the
wheel
ourselves.
A
Okay
back
to
the
agenda
really
quick:
we
have
five
minutes
left
Mike.
You
had
something
on
there
about
agenda
and
meeting
cancellation
discipline.
I
think
we
had
thought
about
this
or
discussed
it
that
we
would
work
on
looking
to
form
the
agenda
prior
to
starting
the
recording,
much
the
same
as
other
communities
do
and
then,
if
we
don't
have
anything
to
talk
about,
then
we
can
go
ahead
and
cancel.
The
meeting
did
I
capture
that
and
repeat
it
correctly
well,.
B
The
except
for
the
assertion
that,
like
other
communities,
because
and
in
fact
in
other
communities,
they
do
a
discipline,
for
example
that
says
oh
well.
Agenda
items
have
to
be
posted
at
least
24
hours
or
48
or
whatever
before
the
meeting
and
the
main
kcp
project
it
looks
like
the
agenda
is
open
until
you
know
into
the
meeting,
so
I
think
we
should
just
explicitly
set
the
expectations
here
of
you
know.
How
long
is
the
agenda
open
and
you
know
at
what
point
do
we?
B
They
were
going
to
cancel
the
meeting
or
close
the
meeting
for
due
to
lack
of
agenda
so
I
think
the
initial
stake
in
the
ground
is
since
we're
operating
in
the
kcp
melu
and
we
are
very
new
Young,
so
it
probably
is
appropriate
to
do
like
the
rest
of
the
kcp
team
is,
which
is
keep
the
agenda
open
into
the
start
of
the
meeting,
but
we
should
just
be
explicit
about
it
is
all
I
was
saying.
B
Well,
I
suppose
it
actually
means
the
end
of
the
meeting
right
so
yeah,
let's
say
that
you
can
bring
it
in
I
know
I
want
to
say
start
of
the
meeting
right.
You
should
have
the
we
should
open
the
issue
well
before
the
meeting,
so
that
people
can
contribute
items
before
the
meeting
and
we've
been
doing
that.
But
you
know
we
should
be
explicit,
so
we
should
explicitly
say
we're
going
to
open
the
agenda.
B
The
issue
at
least
a
week
in
advance
and
people
can
bring
agenda
items
up
to
you
know
like
five
minutes
into
the
meeting,
and
at
that
point
you
know
the
agenda
is
closed
or
or
maybe
we
just
say,
yeah.
The
agenda
is
open
until
the
meeting
ends.
A
I'm,
okay,
with
it
until
it
ends,
does
anybody
have
an
objection
and
by
show
of
hands
to
using
the
term,
ends
the
end
of
the
meeting.
A
Okay,
very
good,
then
by
consensus,
nobody's,
objected
agenda's
open
until
the
end
of
the
meeting,
it'll
close
at
the
end
of
the
meeting.
Of
course,
the
the
agenda
and
the
tissue.
The
issue
that's
associated
with
the
community
meeting-
is
closed
at
that
point
and
the
agenda
I'll
make
sure
it's
open
no
less
than
one
week
before
the
meeting
starts,
I'm,
usually
more
like
three
to
four
weeks
before
the
meeting
starts,
but
in
the
early
days
I
think
it's
it's
good
to
make
this
policy
great.