►
From YouTube: Kubernetes SIG Apps 20191021
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
We
we've
got
a
few
discussion
points,
but
we
don't
have
any
announcements
or
a
demo.
Did
anybody
have
any
announcements
to
make
to
start
this
off?
You.
A
B
A
A
We
drop
the
link
in
I
actually
thought
this
may
be
worked
on
elsewhere,
but
as
I
dug
into
more
of
it,
it
doesn't
look
like
it
is
dropped
in
Lincoln
over
here.
This
is
something
that
I
had
originally
proposed.
The
general
idea
is,
is
there's
a
bunch
of
different
ways
to
get
at
services.
You
can
use
something
like
the
Service
Catalog.
You
can.
C
A
You
go
to
the
operator
framework.
There
is
now
the
or
the
operator
SDK
that's
been
proposed.
They
have
a
system
for
essentially
bringing
in
services
works
really
similar
to
the
Service
Catalog.
You
can
handle
things
like
there's
a
controller
for
an
operator
for
chargebacks,
and
so
you
can
essentially
stand
up
services
in
your
cluster.
But
of
course
everywhere
you
go.
A
You
get
a
different
interface
to
work
with
those
which
makes
it
kind
of
hard
to
specify
and
then
share
all
over
the
place
if
you're
into
sharing
your
applications-
and
so
that's
where
this
was
born
out
of
I
thought
there
was
some
more
work
done
to
try
to
create
a
common
interface
on
top
of
it,
but
I
haven't
found
a
whole
lot
on
it.
I
was
actually
hoping
to
mark
this
as
overcome
or
withdrawn,
but
I
don't
know
that
I
can
because
it
hasn't
been
solved
and
I
also
but
I'm.
A
The
one
who
proposed
it
expecting
to
work
on
it
and
I'm,
not
gonna,
have
any
time
to
work
on
it
in
the
near
future.
That
I'm,
aware
of
so
I,
didn't
know
how
we
should
handle
it.
Should
we
leave
it
sitting
there
as
provisional,
should
we
withdraw
it
for
the
time
being?
Anybody
have
any
thoughts
on
this.
D
A
B
So
the
other
thing
that
and
I
don't
know
if
it's
all
is
the
exact
same
problem:
I'm
not
I
have
to
reach
out
to
like
Sunil
Sally
and
some
of
the
guys
who
were
currently
Red,
Hatters
and
IBM,
and
formerly
Koro
esters
who
are
working.
The
operator
SDK,
but
there's
some
work
to
kind
of
converge
operator
SDK,
not
just
to
use
controller,
runtime
controller
tools,
but
actually
have
Kuby
builder
and
operator.
Sdk
do
the
same
thing
and
part
of
that
conversation
was
like
either
extending
or.
B
A
Yeah
so
I'd
be
curious
to
know.
What's
going
on
with
operator
or
SDK
and
Kuby
builder,
the
operator
SDK
has
been
submitted
to
the
CNC
FTO,
see
for
a
candidate
for
incubation.
There's,
an
open
poll
request
on
it
and
I
think
they
wanted
to
add
in
the
operator
lifecycle
manager,
which
appears
to
be
very
similar
to
the
service
catalog.
Granted.
A
B
They're
working
to
come
so
that
the
metadata
piece
like
OLM
exposes
a
notion
of
subscriptions
and
channels
to
pull
things
in,
and
then
it
has
effectively
a
catalog
of
its
own.
The
common
metadata
is
really
so
that
that
becomes
an
open
kind
of
standard
and
primarily
with
operator
hub
being
like
a
multi
company,
supported
open
source
kind
of
discovery
portal
for
operators.
We
want
everyone
to
be
able
to
consume
them,
not
just
open
shipped
users,
so
that
was
kind
of
where
we're
going
with
it,
but
yeah
I
mean
like
so.
B
There
is
like
a
notion
of
it
getting
badge
to
support,
like
particular
cluster
configurations,
but
being
able
to
consume
it
and
not
having
like
a
standard
for
how
the
metadata
should
be
consumed.
It's
kind
of
it
makes
it
very
hard
for
other
people
to
write
tooling,
that
is
directly
interoperable
with
operator,
so
that
was
kind
of
a
problem
you're
trying
to
solve
well.
A
With
operator
hub
and
the
operator
lifecycle
manager,
it
looks
a
lot
like
a
service
catalog
and
not
other
ways.
You
may
use
operators
and
that's
one
of
the
I've
been
asking
questions
and
I
haven't
gotten
a
good
answer
on
it.
Yet,
but
I'm
trying
to
you
know
what,
if
I've
just
got
one
application
and
I'm,
basically
taking
my
run
books
and
turning
them
into
an
operator
and
I'm,
not
standing
up
many
many
services.
I
know
there
are
people
who
are
using
this
case,
and
so
how
does
that
fit
in
with
something
like?
A
A
A
I
didn't
see
how
it
made
it
easier
to
specify,
though
in
a
selection
of
manifests,
what
you're
going
to
use
and
maybe
also
go
dig
more
into
that.
Okay,
that's
what
I
had
for
that
one.
The
next
one
we
have
is
the
agenda
for
the
coop
con
deep-dive,
ten
or
Janet.
I
know
this
is
yours.
Talk
you
want
to
take
this
yeah.
B
I
just
wanted
to
bring
it
up
to
anybody
who's
here
and
see
if
there
I
get
talking
about
it.
There
are
any
topics:
either
you
can
send
to
the
mailing
list
or
post
the
stock
that
we
should.
You
want
to
be
prepared
to
discuss
and
we
were
kind
of
thinking
that
what
we
would
try
to
do
is
set
the
agenda
at
this
Kubik
on
for
what
we
want
to
try
to
accomplish
over
the
next
like
two
quarters
and
discuss
that.
B
B
A
A
A
E
Hey,
yes,
that's
mine,
I'm,
just
going
to
yeah
I
have
the
Lincoln's
Chad.
Oh
it's
on
the
dock
as
well.
I
just
updated
it.
So
we
really
have
been
hearing
feedback
from
some
internal
users
of
applications.
He
already
that
there
is
a
gap
when
it
comes
to
representing
objects
across
namespaces
and
also
cluster
scoping
in
space
objects.
So
we
feel
that
introducing
a
new
cluster
level
construct
would
be
useful
and
we
can
call
it
cluster
application.
Sorry,
cluster
scoped
applications
here
D.
E
We
can
call
it
cluster
application,
but
maybe
we
can
come
up
with
a
more
generic
named
an
application.
This
is
a
more
overarching
change
for
this
application,
C
or
D
project
I
just
wanted
to
discuss
and
see.
If
it
makes
sense
like,
can
we
call
it
stack
or
can
we
call
it
something
else
that
captures
the
notion
of
something
more
than
an
application.
E
Soft
link,
resources
together
so
that
you
can
have
you
can
get
status
of
all
the
resources
that
are
referred
in
the
applications
here
required.
We
could
extend
this
down
the
line,
so
it
is
more
of
a
representative
object
which
is
a
collection
of
already
deployed
or
something
that's
deployed,
independent
of
application.
Crt,
it's
a
point
of
it's
an
object
that
will
refer
to
all
of
these
other
resources
in
terms
of
management.
It
does
not
do
anything
more
than
just
collect
the
status
of
those
yeah.
A
You're
an
application
operator
who's
focused
on
that.
If
you're
dealing
with
you
know,
different
people
who
are
dealing
with
your
cluster
and
you've
got
separations
of
concerns.
It
might
be
one
set
of
people
who
make
sure
the
cluster
runs
and
another
set
of
people
who
run
the
applications
right.
They're
kind
of
different
roles
here
and.
A
Be
names
based
in
this,
but
it
does
have
certain
features
that
sound
really
great
for
other
cases
like
a
collection
and
in
my
understanding,
maybe
it's
it's
not
an
application
operator
to
do
cluster
scoped.
It's
maybe
somebody's
trying
to
do
a
different
role
and
they're
trying
to
run
something
cluster
wide
I'm
just
trying
to
grapple
with
what
this
means
and
where
you'd
want
to
go
with
it.
So.
E
E
So
when
you
install
all
those
get
install
and
when
you
delete
the
application,
all
of
them
get
cleaned
up
which
is
like
this
is
one
of
the
uses
of
container
but
granted
that
CRD
management
can
be
done
differently,
but
there
are
some
are
back
rules
cluster-level
are
back
to
that
are
tied
to
the
life
cycle
of
the
application.
It's
mostly
useful
in
a
third
service
marketplace
kind
of
environment
rather
than
proper.
A
Okay,
so
this
is,
you
want
to
maybe
install
an
application
and
not
only
tracking
the
applications.
You
know
deployment
stateful
sets
those
kinds
of
things,
but
also
some
of
the
objects
that
have
to
do
with
staining
that
up
in
general,
yeah
yeah
so
so
like
they
are
back
in
figuration.
That
would
be
installed
for
it.
Okay,.
F
Hi,
what
if
I,
could
contribute
to
this
part
of
the
conversation
you
all
haven't
met
me.
My
name
is
my
first
time
joining
you
all.
My
name
is
Chris
vignola
I've,
actually,
a
part
of
a
small
team.
That's
been
using
the
application
CRD
for
a
little
while
and
I
just
wanted
to
ask
if
a
use
case,
that's
relevant
to
this
conversation
about
cluster
scope,
application
CRD
might
be
one
of
the
ones
that
we've
been
wrestling
with.
We've
been
wrestling
with
the
use
case.
Where
we
are,
we
have.
F
We
have
customers
who
are
modeling
applications,
cloud
native
style
applications,
so
a
set
of
micro
services
collaborating
right.
You
know
a
web
UI
or
a
mobile
front
end
or
what
have
you
as
the
user
interface?
They
have
different
teams
to
building
and
deploying
these
various
micro
services,
as
is
rather
common,
some
of
the
services
they
have,
in
fact
they
view
as
shared
services.
They
they
want
to
deploy
them
out.
F
You
know
some
other
set
of
applications
as
well,
and
the
user
wants
to
view
not
only
the
micro
services
and
UI
that
they
deployed,
but
this
shared
service,
as
well
as
part
of
their
view
of
the
application,
because
they
want
to
take
into
account
the
the
the
status
of
all
of
those
of
all
of
those
components
taking
together
as
their
their
view
and
understanding
of
their
application.
So
we
were
wondering
about
that.
You
know
applications
comprise
of
parts
that
are
deployed
across
multiple
namespaces.
We
we
didn't
see
that
as
an
obvious.
F
B
Question
certainly
so
for
the
application
that's
being
consumed
from
another
namespace
by
multiple
services
that
reside-
and
let's
say
so.
Let's
say:
you've
got
some
database
right
like
Maria
DB
right
and
then
you
have
multiple
services
connecting
to
Maria
DB
and
Maria.
Db
is
in
a
namespace
managed
by
like
Murray
VP
admins.
Why
wouldn't
the
the
kind
of
way
we
usually
think
about
that
is?
B
What
we
see
is
that
they're
integrated
via
shearing
coordinates
so,
for
instance,
accessing
that
database
or
accessing
that
micro
service
would
be
done
via
like
a
kubernetes
service
right
or
by
some
other
mechanism
of
sharing
the
IP
address
or
fqdn
allows
you
to
attach
to
the
application
and
the
status.
The
application
is
really
it's
not
kind
of.
It
doesn't
aggregate
up
right
because
it's
very
obviously
coupled
that's
kind
of
how
we
thought
of
it,
but
is
that
sufficient
for
what
you
guys
are
doing,
or
is
that
counterintuitive
I.
F
F
They
have
soft
links
to
not
only
the
things
they've
deployed
into
their
app
one,
an
app
to
namespace,
but
also
soft
length
reaches
out
to
the
the
credit
score
micro
service
in
its
namespace
and
that's
the
and
that's
the
thing
we
weren't
quite
sure
you
know
what
is
you
know,
the
recommended
approach
for
you
know
plying
the
label
selector
beyond
the
namespace
of
the
application.
Sorry,
the
namespace
in
which
the
application
CR
itself
resides.
A
And
I
I
can
kind
of
see
where
this
could
have
some
usefulness
right,
because
if
you're
gonna
go
construct
a
UI,
the
application
CR
would
then
have
everything
you
need
to
even
trace
off
to
dependent
services
by
other
teams
and
if
you've
got
read
access,
you
can
actually
view
what's
going
on
with
those
and
even
if
something's,
maybe
having
a
problem
right
now.
So
you
can
trace
problems
in
your
application
and
you
could
visualize
that
with
you,
I
write
garbage.
E
Yeah,
so
that's
exactly
what
I
wanted,
so
we
did
run
into
issues
where
we
can
be
referred
clusters,
code
resources
and
the
application
object.
The
garbage
collection
went
out
and
randomly
deleted
things.
So
we
don't
know
a
way
of.
We
can
reject
those
in
the
application
controller,
but
this
needs
to
be
documented
and
that's
the
reason
why
we
want
cluster
CR
for
it,
especially
for
these
escape.
A
B
Like
if
it's
something
you
guys
want
to
experiment
with-
and
there
are
obviously
people
who
are
somewhat
interested
I
would
say,
propose
it
and,
let's
you
know,
go
forward
with
it.
I
don't
see
a
problem
like
the
entire
purpose
behind
like
sponsor
subcon
projects
and
so
forth.
Assuming
that,
like
you
and
Anand
and
Janet,
and
like
the
other
people
in
the
cig,
don't
disagree
with
it
is
to
let
people
go
off
and
iterate
and
try
new
things,
and
we
can
always
turn
it
down
if
it's
not
useful.
A
No
I,
like
that.
The
other
thing
that
comes
to
mind
is
I,
think
I
heard
something
in
there
about
managing
CR,
DS
and
I.
Think
that
gets
complicated,
especially
if
you've
got
more
than
one
controller
and
using
shared
informers,
because
you
know,
if
you
say
you
got
two
controllers
looking
for
a
CR
D
and
one
of
them
goes
away.
What
happens
to
the
other
one,
and
how
do
you
know
it
will
level
to
manage
these
things?
Do.
A
Let's
say:
you've
got
two
controllers
watching
separate
namespaces
and
you
go
and
remove
one
of
the
things
I
think
it
was.
You
know
removing
CR
DS,
and
so
you
go
and
delete
a
c
rd
from
a
cluster,
and
then
you
still
get
another
control
in
another
name:
space.
That's
expecting
it
another
CR
DS
gone
yeah.
E
E
This
was
used
by
a
team,
very
tabooed,
install
a
controller
and
then
that's
the
only
control
cluster
scope,
controller
on
on
the
club
yeah
on
the
cluster,
and
then
individual
teams
would
install
CRS
and
in
individual
namespaces.
So
when,
when
the
operator
is
deleting
this
controller,
this
package,
it
means
it'll
clean
up
everything
in
all
the
namespaces.
That's
that's
the
oh
yeah
I.
A
B
B
Or
cube
flow
things
were
effectively
you're
installing
a
lot
of
things
at
clusters,
scope
that
are
going
to
be
shared
and
like
this
is
a
similar
case
to
what
was
being
described
previously.
When
you
have
multiple
deployments
across
the
namespaces
and
dependence
is,
the
hard
part
is
like
if
it's
like
with
this.
Do
you
get
like?
If
you
have
I
mean
some
options?
Some
things
are
optional,
but
generally
you
know
you
need
pilot.
B
If
you're
doing
secrets
you
need
SDS
or
said
it'll,
you
need
all
the
CRS
that
are
associated
with
those
you
need
mixer,
so
you
have
everything
or
nothing
right
and
either
you
install
at
all
and
you
have
a
working
system
or
you
don't
in
those
use
cases,
it's
kind
of
clear
and
straightforward
when
you
have
things
where
it's
like
I
have
two
services
that
depend
on
a
third
and
the
two
front
ones.
You
know
I
I
could
have
any
way.
B
I
can
delete
one
and
it's
tight
entirely
independent
of
a
life
cycle,
the
other,
but
they
both
need.
The
third
that's
really
hard
to
express
using
any
other
tool
and
I've
seen
in
the
ecosystem
so
far,
including
application,
CRD
or
me,
and
you
probably
even
cluster
scopes.
If
it's
not
thought
through
very
careful.
F
A
A
F
So
actually,
yes,
Matt
I,
put
it
into
the
proposed
topics
section
of
the
agenda.
There's
a
some
Microsoft
and
I
think
Alibaba
are
collaborating
on
something
they
call
the
open
application
model,
I've
wondering
if
you
guys
have
seen
that
and
what
you
think
of
it.
It's
interesting
but
I'm
not
sure
what
it
what
it
means
to
the
application
see
argument.
Has
it
been
defining
whether
it
matters
whether
it's
a
another
way
to
to
achieve
what
the
application
CRV
is
yeah.
E
So
I
did
look
at
it.
The
burning
here
I
just
want
to
get
so.
The
notion
of
application
that
Alibaba
and
Microsoft
build
is
a
deployable
object
and
it
is
not
tried
to
cover
it
as
it's
more
of
a
portable
definition
that
will
work
across
given
orders
and
say
function
as
a
service
platform.
So
it
is
different
from
applications
here
like
it's,
not
trying
to
be
a
collection
of
objects,
but
more
of
artifacts
that
can
be
deployed
and
they
are
building
a
controller
which
will
translate
the
specification
into
Cuban.
E
B
A
Yeah,
just
a
scene,
app
is
kind
of
like
a
common
way
of
bundling
things
up.
Helm
does
tgz
files
right
the
scene,
app
kind
of
says:
okay,
if
you're
gonna
run
something
you
need
a
common
packaging.
Here's
the
packaging
with
the
open,
app
model,
I
went
and
I
actually
got
Matt
butcher
the
lead
developer
on
that
on
the
phone
that
day,
it
was
launched
right,
I,
guess:
I
was
gonna,
poke
his
brain
on
it
and
I
haven't
looked
at
it
much,
but
one
of
the
things
that
I
noticed
is
that
it
gives
you.
A
So
if
you're
gonna
go
deploy
production
WordPress
into
a
cluster,
you
need
about
13
kubernetes
resources
to
do
so
and
that
doesn't
actually
get
you
pod
disruption,
budgets
or
auto
scaling
either
right,
so
you
can
actually
add
more
than
those
13
resources.
That's
a
lot
for
somebody
to
need
to
know
and
to
configure,
especially
if
the
person
who's
going
to
do
the
pod
disruption
budgets,
an
operator,
and
that
might
be
different
than
somebody
who
knows
the
application.
That's
going
in
if
you've
got.
You
know,
big
companies
where
you
actually
have
those
two
separate
roles.
A
A
But
their
idea
here
was
is
you've
got
a
definition
for
what
you're
gonna
run
and
then
somebody
can
go
run
it
and
then
they
can
layer
on
traits
that'll
do
things
like
auto
scaling
if
they
know
it
needs
to
be
Auto
scaled
and
it's
a
it's
a
ideas,
there's
also
a
simpler
definition.
You're
not
gonna,
get
everything
that
you
get
in
kubernetes.
You
might
get
I'm
guessing
80%
coverage.
A
E
A
In
kubernetes
llamo
at
this
point,
I'm
learning
that
the
amount
you
have
to
learn
is
becoming
difficult
to
onboard.
I
took
the
kubernetes
API
spec
for
kubernetes,
113
and
I
said:
let's
print
this
to
a
PDF
I
want
to
see
how
many
pages
it'll
be
eight
and
a
half
by
eleven,
and
then
I
thought
my
computer
broke
because
it
took
so
long
to
generate
it
if
I,
just
scoped
it
down
to
just
things,
I
might
need
to
run
workloads,
it
comes
out
over
1,100
pages
printed
and
that's
not
any
of
the
guides
or
anything.
A
That's
just
our
spec
is
huge.
Are
the
amount
of
knowledge
and
I
mean
just
to
run
WordPress
with
a
database?
It's
you
know
at
a
production
level,
you're
talking
thirteen
or
more
different
kubernetes
resources
manifests.
You
got
to
install
it.
That's
not
small,
that's
complicated,
and
so
there
are
folks
out
there
now
working
to
try
and
figure
out.
How
do
you
ease
that
knowledge
and
onboarding?
You
know
go.
Has
this
idea?
You
want
to
fit
the
whole
language
in
your
head
right.
You,
you
kind
of
can't
do
that
with
kubernetes,
even
when
you're
gonna
go.
B
B
If
you
have
this
package,
it's
already
there
for
you
and
getting
it
up
and
running
is
a
lot
easier.
See
Nablus
like
super
super
complicated.
At
least
that
was
a
feedback.
I
was
given,
but
at
the
end
of
the
day,
when
you're
trying
to
troubleshoot
or
if
something
does
go
wrong,
or
if
there's
unexplained
behavior
like
tracing
back
an
alarm
that
triggers
a
page
or
a
flappy
monitor
to
what's
actually
going
on
in
the
cluster.
That's
like
the
hardest
cognitive
dissidence
to
get
over,
and
whenever
you
like,
create
a
separation
from
the
ammo.
B
A
And
some
of
this
gets
into
some
of
the
differences
right
like
I've
done,
apt-get
install
my
sequel
or
apt-get,
install
Postgres
so
many
times
right
and
I.
Don't
need
to
know
the
layout
of
debian
or
every
file
and
everything
about
that
application.
To
do
it
and
I
can
just
get
it
right
and
it
works
pretty
solidly.
But
if
I
had
to
go
troubleshoot
it,
it's
not
going
to
be
a
little
bit
more
of
a
pain
in
the
butt
and
that's
what
package
management
does
take.
A
Somebody
who
knows
both
the
operating
system
and
the
application
and
can
bring
the
two
together.
So
somebody
who
doesn't
have
all
that
expertise
can
go
and
install
it.
That's
that's
package
management
in
a
nutshell,
and
so
that's
what
you
get
in
home,
but
if
you're
gonna
go
run
a
bunch
of
your
own
applications.
When
do
you
wrap
it
up
and
in
a
package
and
then
distribute
it?
I've
worked
at
companies
where
we've
deployed
our
applications.
A
Using
you
know,
Debian
package
is
an
apt
and
I've
worked
out
of
their
company
to
say:
okay,
we'll
do
some
of
our
dependencies.
That
way,
but
we're
not
going
to
do
our
own
bespoke
application
that
way
we're
gonna
do
some
other
things
in
it
and
yeah
you've
got
to
know
a
bit
to
go
troubleshoot
that,
but
if
you've
got
an,
you
know
a
project
with
300,
400,
500
or
more
developers
on
it.
How
many
of
them
need
to
be
able
to
deal
with
something
lightweight
vs.
A
have
to
know
all
of
that
depth,
and
it's
when
you
scale
up
in
these
enterprise
companies
and
the
number
of
people
who
are
working
in
something
and
how
much
knowledge
do
you
need
them
to
go.
Learn
all
of
this
stuff
about
kubernetes.
Well,
they're,
probably
gonna!
Forget
it
cuz,
they
don't
touch
it
very
often.
It's
the
people
who
are
close
to
the
kubernetes
working
troubleshooting
cool,
know
it,
but
those
people
who
are
further
away
in
the
business
logic.
A
How
much
do
they
need
to
know
in
order
to
be
effective
right
if
you're,
a
small
team,
it's
it's
it's
different
than
these
organizations.
I
mean
I've,
worked
on
and
worked
with
projects
that
had
500
engineers
working
on
them
or
more,
and
that
still
boggles
my
mind.
How
you
can
have
something
with
that?
Many
people
on
it,
but
you
know
who
needs
to
know
how
much
stuff
in
order
to
be
effective
on
it.
It's.
B
You
know,
that's,
that's
a
constant
spend
so
yeah
again,
like
I,
don't
have
other
than
like
what
I'm
the
conclusion
that
I'm
coming
to
is
like
there's
really
like.
If
people
don't
understand,
because
if
you're
building
the
package-
and
you
don't
understand
of
cupen
of
these
primitives-
that
you
need
to
deploy,
you
can't
do
it
and
then
once
the
package
is
deployed,
if
you
don't
understand
what
it
actually
did,
you
can't
troubleshoot
it.
So
try
me
I,
I,
just
haven't
been
successful
in
like
elevating
people
above
yeah.
More
so.
A
So
let
me
put
it
this
way,
though
right
so
basically
Heroku
and
Cloud
Foundry.
If
they're
mean
cloud
foundries
working
to
get
kubernetes
as
a
back-end,
you
can
deploy
an
application
with
a
much
simpler
PMO
file
right
and
some
code,
and
then
it
does
the
rest
and
they
don't
know
the
kubernetes
primitives
right
or
the
primitives
to
do
iego,
which
is
what
Cloud
Foundry
is
long
used
and
I'm,
not
sure
where
Heroku
is
and
they're
things
these
days
and
so
I'm
not
gonna
speculate.
A
But
if
you
read
where
they're
going
you
can,
you
can
speculate
for
yourself
and
they
don't
need
to
know
all
of
that
complexity
that
they
have
to
have
in
their
lighter-weight
definitions.
And
it's
made
not
everybody
but
a
whole
lot
of
people
successful
while
needing
to
onboarding
Noah,
not
a
lot
less
right
now.
B
A
Don't
know
but
I
and
I
don't
know
how
good
the
open
app
model
is.
Quite
frankly,
I
haven't
had
time
to
sit
down,
look
at
it
and
play
with
it
and
pick
it
apart,
yet
to
find
what
I
like
and
don't
like
about
it,
but
I
kind
of
understand
why
they're
going
into
this
space
and
just
the
business
problems
in
the
space.
A
F
A
A
E
It's
more
to
do
with
the
mechanics
around
applications
here
already,
so
we
don't
have
a
for
the
cig
sponsored
projects.
We
don't
have
caps,
it's
mostly
we
open
issues
or
how,
if
you
have
to
brainstorm
some
ideas,
should
it
always
be
through
this?
So
it
can
be
just
opening
issues
or
design
issues.
I,
don't
know
how
how
we
should
do
that.
So.
A
Because
this
is
a
sub-project
of
kubernetes,
we
don't
we're
not
required
to
do
see
our
T's
and
and
I
don't
know.
If
we
want
to
change
this,
but
at
least
the
last
time
we
talked
about
it,
the
idea
was
hey.
We
can
be
lightweight
and
more
fluid
and
just
use
issues
unless
we
see
a
need
to
bump
up
to
something
more
formal,
like
caps,
but
so
far
we've
just
kind
of
decided,
hey.
We
can
do
this
lightweight
and
issues
and
talk
about
it
there.
If
that's
like.