►
From YouTube: 20200521 SIG Arch Community Meeting
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
A
Children,
so
in
any
case,
why
don't
we
get
started
there?
A
couple
things
on
the
agenda:
I
did
what
I
say
something
I
know
a
number
here,
I,
probably
for
the
second
item
here.
Unfortunately,
I
didn't
there
was
nothing
on
the
mailing
list
about
this,
and
so
I
personally
have
not
had
a
chance
to
gather
state
about
it.
I'm
talking
about
that
keep
ownership,
so
I
think
that
we
would
be
better
off.
A
So
that's
generally,
our
policy
is
that
these
sort
of
things
like
the
free,
the
first
item
on
the
agenda
here
was
raised
a
few
days
ago
on
the
mailing
list,
gives
everybody
an
opportunity
to
gather
up
their
their
thoughts
about
it
and
for
people
who
are
particularly
interesting
it
to
actually
show
up
the
meeting
we
did
attendance
today.
But
in
any
case,
so
sorry,
if
that's
a
disappointment,
but
if
my
co-chairs
agree
I,
think
that
should
be
deferred
to
the
next
meeting.
A
C
I
can
I
can
give
an
overview
of
this,
so
the
thing
that
prompted
this
was
a
proposal
to
add
api's,
to
cube
API
server,
to
allow
controlling
the
authentication
configuration
for
the
API
servers,
and
so
that
that
was
linked
in
the
mailing
list
thread.
There's
a
there's,
a
open,
kept
PR
around
that
and
that
started
listing
off
leads
trying
to
trying
to
think
about.
C
How
do
we
extend
the
platform?
What
are
the
different
dimensions
of
extensibility
and
what?
What
is
sort
of
the
reasoning
behind
the
different
types
of
extensions
we
provide
and
support
and
where,
where
we
expose
those
how
we
expose
those-
and
so
the
goal
here
is
to
kind
of
share
some
of
that
thinking.
Hopefully
so
it
helps
other
SIG's
other
components
that
are
also
trying
to
think
about
reason
about
their
extension
mechanisms.
C
This
represents
at
least
a
few
hours
of
untangling
our
thoughts.
So
hopefully,
these
dimensions
are
helpful
to
share
and
think
about,
but
then
also
to
kind
of
ask
questions
about
how
people
are
thinking
about.
Cluster
configuration.
Api's
versus
api
is
served
by
the
cube
api
server.
So
that's
one
question
and
then
the
second
one-
and
this
was
brought
up
in
the
mailing
list
discussion.
How
does
sort
of
a
path
to
being
included
in
conformance.
C
C
So
those
those
are
the
three
things
that
I
was
kind
of
wanting
to
cover
here.
Just
if
people
had
thoughts
about
these
dimensions
of
extensibility
other
ways
of
thinking
about
it
additional
things
they
think
we
missed.
That
would
be
helpful
to
maybe
add
to
this
body
of
knowledge
and
then
those
two
questions
like
do.
We
do.
We
distinguish
between
cluster
configuration,
api's
and
cube
api
server,
api's
and
the
conformance
question.
D
C
Yeah
decision
trees
that
kind
of
help
us
think
about
things
like
this,
so
that
if
a
proposal
comes
up
and
we've
already
thought
through
like
is
this
more
of
a
cluster
configuration
API?
If
so,
then,
maybe
it
belongs
in
cluster
API
or
something
similar
and
not
in
a
built
in
queue.
Api
server,
API,
a
decision
tree
like
that
is
hopeful.
C
Similarly,
a
decision
tree
like
based
on
feedback.
This
would
not
be
acceptable
in
some
percentage,
some
significant
percentage
of
environments-
it
doesn't
look
like
this-
would
be
reasonable
to
including
conformance.
Therefore,
we
don't
think
it
should
be
a
built
in
API,
so
decision
trees
like
that,
are
helpful
and
look
kind
of
both
of
those
both
of
those
things.
The
boundaries
of
what
should
be
in
the
API
server
and
the
conformance
aspects
are
things
that
touch
shake
architecture.
One.
C
B
B
We
also
have
some
api's
that
we
haven't
fully
promoted
that
went
down
various
paths
that
I'd
want
to
use
this
as
an
opportunity
to
maybe
reflect
on
so
dynamic
cubic
configuration
is
a
situation
where
I
feel
like
we
started
down
a
path
that
we
haven't
really
fully
finished
and
I.
Think
I
can't
identify
a
user
who
has
enabled
it
and
I'm
wondering
if
we
should
reflect
on
that
as
we
evaluate
it.
Guys
like
this.
A
F
It's
hard-
this
is
a
pretty
large
call
just
to,
as
it's
been
pointed
out,
it's
weird
for
us
to
have
a
bar
around
conformance,
because
I've
worked
on
confirmes
for
so
long
as
being
the
gate,
because
it's
very
inconsistent
with
what
we
do
today,
so
I
think
as
kind
of
maybe
as
Dirk
pointed
out,
is
that
we
need
to
rationalize
kind
of
what
we
have
today,
along
with
any
criteria.
We
want
to
put
forwards
towards
the
future,
because
otherwise,
it's
way
too
arbitrary,
myrrh
to
say
like
it,
must
meet
this
bar
going
forwards.
F
G
B
I
want
to
say
two
years
ago
there
was
an
effort
to
allow
the
cubic
configuration
to
be
changed
dynamically
right.
So
if
you,
you
wanted
a
cube,
API
surface
to
go
and
say
enable
this
cube
looks
like
you
could
do
that,
and
you
had
a
link
on
a
node
that
says
this
is
where
my
cubic
config
is,
and
then
the
cubic
had
a
complicated
orchestration
procedure
to
roll
out
that
new
config.
B
My
experience
on
this
is
that
the
feature
I
think
did
reach
a
beta
status,
but
I
don't
think
any
anyone
is
actually
using
it
in
production
and
I.
Think
it's
fair
to
say
that
in
signal
I
wouldn't
encourage
users
to
use
this
right.
Now,
one
of
the
issues
that
I
think
comes
up
with
cubic
configuration
as
making
that
surface
configurable.
B
Was
insufficient
when
you
didn't
make
the
container
runtime
or
operating
system
itself
configurable?
So
it
wasn't
like
you
had
one
uniform
config,
you
could
apply
across
all
clusters
and
everything
was
going
to
be
great
when
dealing
with
how
cubic
configuration
was
laid
down.
So
my
personal
feeling
was
knowing
what
I
know
now.
I
would
probably
have
cautioned
us
against
doing
cubic
config
dynamically,
but
that
I'm
not
sure
if
other
components
to
memory
have
explored
similar
things.
A
All
right,
I,
don't
see
a
way
to
raise
my
hand
I'm
a
new
client
but
I'll
make
its
comments
and
then
it's
2-mile,
Claire
and
daniel
Smith.
So
with
respect
to
conformance
I,
think
that's
an
interesting
idea.
The
Jordan
raise
but
tiny
I'm
a
little
bit,
leaning
toward
listen
to
me,
saying
that
I'm
not
sure
that
that's
the
right
bar.
H
A
B
B
C
I
A
We
are
working
on
that
issue
is
the
in
the
conformance
program,
things
that
are
not
mandatory
for
cluster
operators
that
are
sort
of
always
always
on.
We
don't
currently
have
a
mechanism,
although
we've
made
progress
towards
it,
it's
slow-moving,
but
we're
making
progress
towards
having
away
such
that.
Essentially
we
can
say
if
you
enable
this
functionality,
then
it
must
behave
in
this
way.
Yeah.
I
G
A
I
And
I
was
just
gonna
like
to
add
to
Derrick's
point
on
cubed
came
together
like
really
wanted
a
hammer
on
the.
What
we
made
dynamic
was
not
the
right
thing
or
the
argument.
The
lesson
there
is
what
we
made
dynamic
was
not
the
right
thing,
which
is
when
we
had
very
nearly
scoped
things
we
make
dynamic
like
compute
and
services,
and
all
of
that
like
we
designed
to
have
a
dynamic
system
where,
as
they
can
take
through
the
cubelet,
we
didn't
make
such
a
distinction.
I.
Think
that's
like
the
the
salient
lesson.
I
Whatever
extension
point
exists
has
to
have
a
really
clear
use
case
that
has
value
for
a
set
of
scenarios
and
has
to
have
justify
its
value.
Just
doing
dynamic,
config
of
a
component
I,
don't
think,
is
sufficient.
Like
we've
never
made
the
scheduler
config
generic
and
I
would
certainly
caution
against,
for
instance,
if
the
schedule-
and
this
looked
totally
hypothetical
but
like
if
the
scheduler
wanted
to
change
priorities
and
make
that
dynamic,
there's
lots
of
people
who
the
scheduler
is
inadequate.
B
F
I
think
I'm
next
cuz
I've
been
Kim,
attract
green
mister
all
cleared.
He
can
lower
your
hand,
I
think
that
all
otherwise
so
I've
been
around
and
both
producer-consumer
for
dynamic
could
the
config
on
the
cluster
and
lifecycle
side,
and
although
the
implementation
was
not
actually
what
exactly
what
we
wanted
and
I
think
there
was
boundary
lines
that
were
crossed.
As
Clayton
pointed
out.
There
is
definitely
demand
from
the
wild
to
be
able
to
modify
certain
sets
of
configurations.
There
should
be
like
a
classification
like
there's
static,
configurations,
things
that
you
shouldn't
change.
F
It
can't
change.
Then
there
are.
There
are
things
that
are
potentially
runtime
configurations
where
you
can
actually
modify
them
either
on
the
fly
and
then
there's
like
a
partial
runtime
configuration
which
cause
a
process
to
restart.
That's
said,
like
we've,
never
had
that
delineation,
clearly
demarcated
inside
of
how
we
do
things.
We
never
had
dynamic
configuration
plumbed
through
the
whole
system.
F
It's
very
ad
hoc
today.
The
promise
of
a
grand
unified
field
theory
of
component
config
is
what
Lucas
always
we've
always
talked
about
and
wished.
We
had
from
the
cluster
of
life
cycle
perspective
because
we
treat
config
in
the
same
way
we
never
got.
There
was
never
really
funded
from
a
community
perspective,
we've
kind
of,
as,
as
Derek
pointed
out,
it's
like
it's
got
to
a
certain
point,
then
just
kind
of
stopped
and
not
been
revisited.
F
That
said,
there
is
demand
there
exists
precedent
all
over
the
codebase
there's
stuff
in
the
component
config
in
the
proxy
there's.
This
weird
mecca
nation
that
actually
exists
inside
the
scheduler,
which
causes
a
hard
restart
on
the
config
for
weights
and
balances.
So
it's
just
inconsistent
I
think
the
demand
is
there,
the
need
is
there
I
think
the
enumeration
has
not
been
clean.
The
defined
and
the
boundaries
have
been
clearly
defined.
F
E
Think
one
of
the
signs
for
me
like
in
this
particular
example,
is
that
we
see
people
hacking
around
to
introduce
new
auth
mechanisms,
because
it's
so
difficult
to
install
at
the
API
server
level,
and
so
one
example
is
like
you
look
at
rancher
and
they
have
essentially
a
way
that
they're
abusing
service
account
jobs
to
provide
user
accounts
in
the
system,
because
it's
so
difficult
to
actually
apply
this
stuff
in
a
consistent
way
across
all
the
different
distributions
in
ways
that
people
have
to
manage
this
and
so
I.
Think
in
this
particular
case.
E
That's
that's
an
example
there
and
then
the
other
point
I
want
to
make
is
that
you
know
for
a
long
time
now,
we've
been
taking
the
control
plane.
By
being
a
fixed
idea
to
being
something
that
is
really
sort
of
more
Fuzzle
e
defined,
like
is
a
webhook
part
of
our
control.
Plane
are
not
part
of
our
control
plane
and
we're
doing
this
more
and
more
and
more,
and
so
is.
E
I
What
do
you
mean
by
break
users
right
like
if
you're
sending
a
request,
an
API
request
and
API
server
gives
you
back
to
500
and
the
result
is
some
component?
That's
not
API.
Server
like
some
default
is
somewhere
else,
like
whatever
caused
that
failure
as
part
of
the
control
plane.
That's
how
that's
my
mental
rule.
Okay,.
E
And
I
would
actually
say
from
the
users
point
of
view:
core
functionality
is
part
of
it
and,
like
you
know,
let's
take
a
look
at
sort
of
the
the
ingress,
v2
gateway
stuff.
That's
going
on
right,
it's
more
likely
that
we're
gonna
take
stuff,
that's
built
into
the
control
plane
now
and
actually
move
that
out
and
to
be
a
CR
D
type
of
thing
that
sits
on
the
outside.
So
we're
gonna
have
fundamental
functionality
that
is
layered
on
from
the
outside,
using
crts
and
so
yeah
I
mean
I.
E
Think
we
can
look
at
the
control
plane
from
sort
of
the
strict
like.
Are
we
returning
five
hundreds?
But
then
we
can
also
look
at
the
control
plane
in
terms
of
core
functionality
and
we're
moving
more
and
more
to
that
stuff
to
run
on
cluster
being
dynamically
configured
and
and
so
I.
Don't
think
that
there's
a
clean
line
here
so
I'll,
let.
H
E
G
G
G
A
A
A
But
I
think
that
mean
if,
if
we're
talking
about
functionality,
that's
sort
of
at
the
cluster
operator
level,
then
the
ability
for
managing
that
and
the
responsibilities
of
that
is
going
to
be
with
that
cloud
provider.
Look
them
up
the
cloud
provider
to
kind
of
thread
that
weird
line
between
what
they
give
to
it
because
where's
your
monthly
go
Wow.
But
you
know
the
the
additional
risk
associated
with
exposure
of
you
know.
J
G
G
I,
don't
follow
how
that's
possible
I'll
do
local
static.
Config
is
always
considered
first
right.
So
if
you
do
it
that
way,
you
guarantee
that
the
only
time
you
ask
the
remote
config
is,
after
all,
the
local
configure
says:
I,
don't
know
what
this
request
is
for
right.
So,
by
definition,
if
you
were
getting
a
500
is
because
everything
local
says,
I
don't
know
what's
going
on
and
then
the
remote
thing
says
I
also
don't
know.
What's
going
on
and
no
matter
what
your
request
was:
gonna
get
denied
I.
I
H
Thanks
I'm
gonna,
add
on
to
where
I
think
Moe
was
going
with
this
John
a
few
minutes
ago.
You
said
you
mentioned
about
hosting
providers
taking
on
burden
and
in
this
case,
as
a
customer
I
look
at
more
like
what
are
my
rights
as
a
user.
Are
there
certain
things
that,
if
a
maybe
this
gets
into
conformance,
but
if
a
hosting
provider
says
they're
offering
kubernetes
to
me,
I
would
like
there
to
be
certain
capabilities.
H
That
I
know
are
available
to
me
as
a
consumer
that
they're
not
gonna,
cut
me
off
from
and
I
still
like,
because
I've
been
cut
off
from
being
able
to
integrate
my
own
authentication
system
all
over
the
place.
I
know
exactly
how
it
works,
and
yet
I'm
not
allowed
to
do
it
in
too
many
times,
because
I
either
opted
to
take
on
the
burden
of
operating
the
cluster
entirely
myself
or
I'm
told
that
as
a
customer,
I
don't
have
that
right,
because
I
can
do
something,
I,
don't
know
dangerous
or
something
so
I
see.
H
Some
of
this
stuff
is
not
just
the
dimension
of
how
dynamic
it
needs
to
be,
but
really
who
has
the
right
to
determine
what
is
available
to
the
cluster
operator
and
maybe,
as
I,
saw
a
point
made
of
very
early
on.
Maybe
this
belongs
in
the
cluster
API
if
we
could
compel
hosted
offerings
to
actually
on
or
something
like
that,
so
maybe
it
is
something
that
is
only
important
when
the
cluster
is
first
created
against
this
question
of,
should
I
be
guaranteed
that
I'm
allowed
to
configure
this
as
a
customer.
If.
A
Is
exactly
the
purpose
of
conformance
is
to
provide
a
guaranteed
set
of
functionality
for
end-users,
so
they
can
know
their
workloads
work
consistently
across
those
environments.
So
I
think
that
that's
a
great
point.
It
really
comes
into
play
when
we
decide
whether
this
cosmetic
performance,
which
matches
all
the
way
up
to
join
its
point
of
shouldn't
that
be
a
consideration
early
on
in
whether
it
becomes
a
built
in
API
or
not,
which
I
think
we've
discussed
a
little
bit
but
conclusion
I'm
Jordan
next
and
then
Tim.
C
Little
wear
my
hat
there
we
go
gathering
a
few
thoughts
so
back
to
Tim
st.
Clair's
coming
about
component
configuration,
I
am
in
favor
of
describing
configuration
in
structured
ways,
I
think
that
has
a
lot
of
benefits.
It
lets
the
example
of
if
this
was
to
be
surfaced
and
controllable
via
a
custom
resource.
A
natural
way
to
describe
that
would
be
to
have
that
custom
resource
include
the
config
snippet
that
would
be
given
to
the
API
server.
B
H
Word
with
use
I
think
of
it
as
operator.
In
other
words,
it
is
true
that
a
user
who
you've
blessed
to
do
things
like
create
config,
Maps
they'll
be
perfectly
happy
with
a
system
like
that,
but
your
organization
might
not
even
allow
you
to
roll
it
out
to
users
like
that.
If
certain
other
authentication
things
can't
be
put
in
place.
K
So
I'll
start
I
have
to
two
points:
I
am
sitting
in
the
chat
and
mostly
agreeing
with
what
Joe
is
saying:
I,
don't
have
a
strong
feeling,
whether
a
provider
specific
API
for
twiddling
knobs
or
a
common
policy
for
twiddling,
knobs
or
comment
API
rather
but
I
do
think
it's
important
that
providers
be
able
to
say
which
knobs
they're,
ok
with
you
twiddling
or
not.
If
we
want
to
do
dynamic
configuration
of
things
like
flags,
that's
totally
cool,
but
I.
Think
providers
need
to
be
able
to
say,
like
I
can't
support
it.
K
If
you
twiddle
display
and
to
to
the
question
about
rights,
I
think
the
default
position
for
everything-
that's
not
otherwise
specified
is
it's
up
to
the
provider
to
decide
if
you're
allowed
to
twiddle
it
or
not,
the
providers
are
offering
you
different.
You
know
benefits
for
using
them.
Some
some
are
supports
in
SaaS,
some
are
low
costs.
Some
are
SR
ease,
whatever
the
trade-offs
you're
getting
from
your
provider.
K
If
you
don't
like
the
knobs
that
they're
allowing
you
to
twiddle,
either
vote
with
your
wallet
or
Lobby
them
to
change
it
and
the
exception
case
there
should
always
be.
If
we
as
a
community,
decide
it's
really
important
for
somebody
to
be
able
to
configure
something
like
authentication
and
we
add
an
extensible
API
for
it
like
web
hooks
and
CR
DS,
then
cool
that
thing
was
part
of
conformance
and
providers
will
have
to
think.
That's
how
you
can
lobby
the
providers
to
the
question
at
hand.
I
actually
have
no
strong
opinion.
K
I
I
just
want
to
say
something
I'm,
slowly
putting
back
in
to
catch
all
this
stuff.
We
went
through
four
other
extensibility
features
like
books
and
CDs,
and
we
felt
it
was
pretty
important
at
the
time
to
get
those
conformance,
tested
and
basically
mandate
them
everywhere
under
the
theory
that
an
extensibility
feature
isn't
really
useful.
Unless
you
can,
you
can
use
it
anywhere.
I
Right
like
the
idea
is
like
the
whole
promise
of
kubernetes
is
working
with
portability
right,
but
as
your
workload
starts
to
include
parts
and
aspects
of
the
control
plane,
you
need
to
take
those
with
you
to
write.
Your
application
isn't
really
portable
if
it
depends
on
the
C
or
D,
and
you
can't
take
that
C
or
D
somewhere
else
with
you.
I
So
if
the
argument
is
that
this
is
a
an
extensibility
feature
for
users
and
users
will
rely
on
being
able
to
take
their
identity
system
around
with
them
like
this,
then
it
really
ought
to
be
conformance,
tested,
right
and
mandated.
But
if
it's
not
that
sort
of
extensibility
feature,
then
maybe
it
doesn't
need
to
be
dynamic
either.
That's
that's
how
I
think
about
it.
E
So
just
a
some
of
the
stuff
I
was
saying
in
the
chat:
I
think
you
know
having
the
capability
versus
having
the
pot.
You
know
allowing
that
as
two
separate
things
having
a
standard
API
for
how
you
do,
that
makes
it
easier
for
end
users
and
consumers
to
say
I
want
you
to
enable
X
right
versus
saying
I
want
you
to
enable
me
to
do
this
flag
doing
it,
and
you
have
to
plummet
through
sort
of
like
some
other
type
of
system,
to
be
able
to
do
that.
E
So
I
think
it
really
creates
a
clear
way
for
consumers
to
ask
for
that
capability.
Now,
with
respect
to
conformance.
You
know,
I've
said
for
a
long
time,
but
I
haven't
put
the
work
in
to
try
and
make
it
happen.
So
take
that
for
what
it
is,
we
should
have
probably
different
buckets
of
conformance
with
logos
and
levels
to
go
with
it,
and
so
then,
like
you
know,
I
want,
like
you
know,
you
know,
cluster
control
level
three
means.
Okay,
you
get
to
control.
This
particular
I.
Think
there's
stuff
that
can
be
done
there
I.
E
Don't
think
that
conformance
necessarily
needs
to
be
an
all-or-nothing
type
of
thing
in
terms
of
like
allowing
this,
and
actually
like,
like
one
of
the
scenarios
that
I'm
looking
at
here,
is
that
you
look
at
something
like
open
shift
and
it
has
a
built-in
olaf
server,
that's
integrated
into
it.
That
allows
you
to
do
something
like
deploy
a
dashboard
that
allows
end-users
to
be
able
to
log
into
the
dashboard
and
then
further
authenticate
to
the
api
server
in
a
unified
way.
E
You
know
providing
the
mechanisms
for
people
to
start
exploring
what
it
means
to
be
able
to
play
with
different
auth
systems
in
the
way
that
they
can
integrate
this
in
automated
ways,
whether
that
be
a
dashboard
or
whether
it
be
other
tools
that
are
actually
automating
across
multiple
clusters.
Coming
from
different
vendors,
that's
a
huge
value
plus
to
end-users
to
be
able
to
actually
have
a
consistent
tool
story,
including
authorization
that
they're
using
across
all
of
their
clusters.
And
for
me,
that's
the
real
end
user
benefit
that
we're
driving
here.
E
C
C
Extending
the
current
support
for
a
single
YDC
provider.
That's
configured
when
the
cube,
API
server
starts.
Extending
that
to
support
multiple
would
give
people
who
are
configuring,
a
cube,
API
server
tools
that
would
let
them
support
this.
It
wouldn't
require
it,
it
wouldn't
add
a
built-in
API.
It
wouldn't
raise
the
questions
about
conformance
and
all
of
that,
but
it
would.
It
would
add
tools
to
allow
this,
then
allowing
providers
to
expose
that
via
C
or
D
or
via
cluster
api
or
via
different
mechanisms.
C
C
A
That,
in
particular,
I
mean
I
think
that
second
architecture
isn't
really
an
escalation
point
for
overriding
TLS
of
states
when
they've
made
a
decision,
and
what
we
can
talk
about
here
are
the
kind
of
meta
points
that
they
come
up
around
like
architectural
II.
Do
we
want
principles
around
this
and
around
how
we
decide
whether
some
things
available
as
a
runtime.
B
A
Versus,
if
a
you
know
a
flags
or
a
or
a
file
and
I
think
we
can.
You
can
have
that
discussion
here,
but
you
know
that
the
TLS
of
that
sitting-
really
it
are
ultimately
once
you
make
the
decision
in
this
particular
case,
then
I
don't
know
that
it's
appropriate
necessarily
from
seeking
architecture
to
somehow
write
them
or
even
have
athlete's
42.
A
C
Just
before
we
move
on
I
didn't
want
to
say
like
I
when
I
was
reviewing,
the
cap,
I
was
trying
very
hard
to
understand
like
specific
requests
and
specific
gaps
in
the
current
extension
mechanisms.
The
API
server
supports
and
right
now
supporting
only
a
single,
oh
I
deceive
a
writer
seems
to
me
like
a
gap
that
we
could
fix
without
Radek
altering
the
exposure
of
the
current
configuration
that
would
allow
addressing
the
biggest
requests
that
I've
seen
and
we're
linked
from
the
cab.
C
G
I
guess
so,
on
the
whole
like
having
multiple
ITC
providers
right,
like
the
the
part
that's
concerning
there
is
right
like
we're.
Gonna
well
do
work
in
treat,
which
is
fine.
We
always
have
to
do
stuff
in
there
edge,
but
then
we'll
have
to
do
work
out
a
treat.
That's
also
fine,
maybe
one
time
kind
of
work
right,
but
the
part
that's
a
really
hard
sell
is
we're.
Gonna
then
ask
every
single
provider
to
go
wire.
G
C
G
C
G
G
G
A
So
I
think
we're
again
we're
actually
try
to
blow
on
time
here
and
we're
starting
to
drilling,
to
really
a
discussion
that
that
is
between
the
on
sing-off
and
maybe
she
sings,
as
opposed
to
a
policy
discussion
around
like
what
are
the
principles
behind
are
extensible
functions.
So
I
hear
you
that
year,
you
know
you're
concerned
that
it.
You
know
it
creates
additional
work
and
like
given
the
interest
of
time
some
of
other
people
that
want
to
talk.
I,
think
that
discussion
probably
needs
to
be
revisited
and
sit
out
there
treatment
grants.
B
A
Don't
know
exactly
where
or
continued
on
BLS
you
know
unless,
but
let's
let
the
next
dump
I
think
was
Clayton
was
not
just
yeah.
I
I
wanted
to
drill
on
the
meta
point
the
Jordan
brought
up,
which
is
into
Jose
as
well
like
it's.
The
only
way
that
you
could
accomplish
something
that
is
fairly
reasonable
and
by
fairly
reasonable.
We
actually
need
a
bar
for
what
that
is,
is
to
put
code
into
cube.
Api
server
were
probably
not
done
in
terms
of
adding
mechanisms,
but
I
would
probably
say.
I
I,
wouldn't
I,
wouldn't
feel
like
the
first
place
that
we
would
start
a
mechanism
is
allowing
the
using
a
lower-level
primitive
to
accomplish
that
in
the
short
run
so
like
like
in
just
in
this
example
like
it
should
be
possible
to
do
server
integrations
that
let
you
do
a
loss,
integration,
cleanly
or
IDC
integration
cleanly.
But
if
you
can
use
a
lower
level,
primitive
I
think
that's
where
we
should
start
and
the
bar
like
when
we
think
about
what
we
define
as
a
bar,
like
we
should
figure
out
a
way
to
capture
this
into.
I
I
That
is
obviously
something
we
should
take
on
and
over
time
and
like
this
project,
we
dropped
that
Bart
like
that
bar
has
gotten
higher
and
higher,
like
you
have
to
do
a
lot
to
move
the
needle,
and
we
still
have
a
lot
of
other
things
that
we're
trying
to
work.
But
if
you
can't
do
it
at
all,
I
think
that's
the
easiest
one
for
like,
as
Jordan
was
saying
in
the
specific
case.
You
can't
do
it
at
all.
A
A
I
Really
concrete
example:
we
have
a
mission
webhooks,
they
don't
solve
every
problem,
there's
things
that
people
do
to
fork
the
API
server
to
accomplish
that
running
custom
code,
there's
a
bar
where
you
cross
the
line
from
running
custom
code
in
a
cube
api
server
to
something
like
an
admission
web
hook,
there's
a
middle
ground
which
is
the
lower
level
primitive.
We
should
make
sure
we
have
those
as
necessary
to
accomplish
these,
but
I.
Think
the
bar
between
that
in
the
next
higher
level
is
growing
over
time
of
this
project.
It
should
be
possible,
it's
just.
G
I
That's
like
30
minutes
discussion.
We
probably
ran
out,
but
it
was
just
a
very
brief
like
that,
when
we
were
trying
to
come
up
with
a
framing
for
this
one
of
them
was
we
have.
We
started
by
being
very
workloads
specific
and
we
left
the
door
open
that
we
could
be
a
meta
meta
provider
and
you
can
install
these
api's
and
Brendan
for
us
just
to
put
a
bunch
of
code
in
and
we
all
hated
him,
and
then
we
did
it.
I
It
turned
out
to
be
good,
but
like
extending
the
API
servers,
adding
a
really
setting
webhooks,
we
did
that
to
specifically
grow
the
ecosystem
for
the
end
app.
But
there
are
a
lot
of
people
who
found
value
in
the
meta
of
the
loopback
for
managing
the
platform
itself,
or
you
know,
injecting
things
that
make
the
platform
more
powerful
for
all
the
components.
E
You
could
actually
layer
that
on
top
of
this,
and
so
in
my
mind,
the
you
know,
a
good
test
of
extension
capabilities
is
if
you
can
actually
find
more
universal
truths
that
are
lower
level
than
the
stuff
that
you
had
to
hack
in
there
I've
always
been
very,
very
uncomfortable
with
the
the
CSR
stuff
and
so
talking
about
the
cubelets.
Actually,
you
know
I
see
Dan
I
see
Daniels
down
there
talking
about
the
cubelets
using
the
CSR
stuff.
E
There
is
no
reason
why
that
couldn't
have
been
built
on
the
outside
and
actually
built
into
some
of
the
cluster
API
cube
admin
stuff.
In
fact,
we
actually
did
some
stuff
as
part
of
that
for
cube
admin.
That
was
some
of
the
proto
work
for
the
CSRs.
There
was
there's
absolutely
no
reason
that
that
has
to
be
built
in,
and
so
I
think
this
is.
C
C
Exact
based
client
authentication
did
not
exist,
so
the
ability
to
give
a
qiblah
to
keep
config
and
it
stay
like
I'm
gonna,
make
an
API
call,
go,
get
the
cred
and
like
be
able
to
get
it.
What
deal
whatever
mechanism
you
wanted?
None
of
they're
all
one
of
those
things
did
not
exist
if
they
had.
It
is
likely
that
the
csr
and
people
had
bootstrapping
stuff
would
look
different
and
and
would
have
been
built
on
top
or
as
an
extension,
yeah.
E
C
C
J
A
A
D
F
D
A
A
Okay,
well,
thank
you,
everybody.
Obviously,
the
baking
agenda
I
think
that
hippy
has
volunteered
to
write
this
up
the
notes
and
try
to
summarize
and
send
it
out
to
the
mailing
list.
So
please
look
forward
to
that
and
reply
and
you
know
clarify
whether
it's
accurate
or
not,
if
probably
easiest,
if
you
put
that
in
a
Google
Doc,
and
then
people
can
comment
on
it
as.