►
Description
Want to view more sessions and keep the conversations going? Join us for KubeCon + CloudNativeCon North America in Seattle, December 11 - 13, 2018 (http://bit.ly/KCCNCNA18) or in Shanghai, November 14-15 (http://bit.ly/kccncchina18).
SIG Apps Intro – Janet Kuo & Kenneth Owens, Google (Any Skill Level)
Join Kubernetes SIG Apps to learn about the areas of our focus, what we are working on currently, and how you can get involved. Veteran SIG Apps members will be on hand to help answer questions.
"About Janet Janet is a Software Engineer for Google Cloud. She joined the Kubernetes project before the 1.0 launch in 2015. She is an active SIG Apps contributor and the owner of Kubernetes workload APIs. She strives to build the best experience for running workloads in Kubernetes.
About Kenneth
He is a software engineer at Google.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
A
A
So
as
it
saying
that
current
chairs
are
Anand
abou,
the
same
from
bitNami,
he
couldn't
be
here
today,
unfortunately,
and
neither
could
Matt
Farina
with
Samsung,
recently
retired
from
mistake
and
one
of
the
founders
was
Michele
neroli.
She
is
here
not
in
the
room,
but
at
the
conference.
Microsoft
er,
formerly
of
dias
and
she's.
Currently
a
Medicaid
steering
committee.
A
So,
let's
talk
a
little
bit
about
what
sig
Apps
is
that's
what
I
do
that
inspire
goals,
so
primarily
what
we
do
is
we
discuss
running
into
finding
applications
in
kubernetes.
These
are
api's
SDKs.
The
core
controller
is
the
workload
controllers
package
management
tools
like
helm,
other
tools
like
draft
and
compose
case
on
it.
We
were
to
improve
the
workloads
API
to
better
support
application
development.
A
lot
of
the
people
might
say
all
of
the
people
who
are
contributor
to
the
workloads,
API
or
members
of
sig
apps,
and
tend
to
attend
so
like.
A
If
you
look
at
apps,
they
generally
leverage
the
workloads
API,
so
that
interface
between,
let's
say
Helmer
case
on
and
kubernetes,
tends
to
be
the
workloads
API
for
people
who
don't
know
what
that
is.
It's
deployment
demon
said
replica,
said
pod
so
forth,
and
so
on
so
sig
apps
acts
as
a
forum
for
the
community
operators,
administrators
tool
developers
to
interface
with
people
who
are
kubernetes
contributors
and
even
potentially,
to
become
the
court
could
burn.
I
expect
contributors
if
they
want
to
the
other
thing
that
we
kind
of
do
is
so.
A
Kubernetes
is
kind
of
a
tiered
stack
right
like
one
of
the
most
external
API
is
for
most
people
is
Apps,
the
staple
set
demon
said
replica
set
deployment,
but
these
leverage
other
Plymouth's,
which
Brian
calls
and
Tim,
tend
to
call
nucleus
primitives,
like
services,
storage
and
then
coolant
and
the
API
server
API
machinery.
We
will
also
act
as
an
interface
to
kind
of
look
at
what
people
are
doing
in
the
community,
drive
the
development
of
the
workloads,
API
and
drive
requirements
into
the
core
and
ended
nucleus
to
make
modifications
there.
A
We
try
to
be
the
voice
of
people
running
applications
in
kubernetes
as
well
so
people
who
are
coming
into
the
community
saying
you
know
this:
will
this
works
really
well?
For
us?
This
doesn't
work
really
well
for
us,
these
are
the
requirements
we
need.
This
is
what
your
system
does
well,
these
are
the
production
use
cases
it
doesn't
solve
will
be
a
voice
in
the
overall
community
and
carry
those
messages
back
to
the
steering
committee
and
to
sig
architecture
and
say
well,
look,
you
know
we're
Googlers,
and
we
did
this
thing.
A
We
wanted
to
run
at
Google
scale,
but
for
that
you
know
the
smbs
or
for
the
startups,
the
requirements
aren't
really
needing
meeting
their
needs
start
early
solving
their
problems,
and
we
should
probably
do
this
instead
and
we
try
to
encourage
contributions
from
the
community.
So
we
do
our
best
to
try
to
Shepherd
commits
from
people
in
cig
apps
into
the
API
and
into
kubernetes,
and
we
love
demos
and
features
and
that's
kind
of
a
way
that
drive.
B
B
And
then
we
just
talked
about
and
what
close
API
so
and
how
many
of
you
are
familiar
with:
foreclosed
api's,
okay,
I
see
a
few,
so
I'll
give
an
overview
of
those.
What
close
API
is,
and
both
Ken
and
I
are
developers
on
were
close
API.
What
were
close
API
means
is
that
that's
the
API
is
that
kubernetes
provides
for
you
to
run
your
pods
and
they
are
going
to
be
running
in
different
patterns.
So,
for
example,
we
have
the
Steelers
for
clothes
and
that's
managed
by
the
first
three
API
is
the
first
one.
B
B
For
example,
you
have
your
web
applications,
you
can
run
it
in
your
endo
deployment
and
also
deployment
supports
the
rolling
update
feature
and
you
can
also
roll
back
and
then
there's
and
also
it's,
and
so
we
have
a
concept
called
API
version,
so
you
have
an
API
group
and
a
virgin
v1
means
that
it's
so
it's
under
apps
v1.
That
means
it's
v1.
It's
GA
and
Apps
means
it's
under
the
app
API
group.
B
Then
there
is
the
the
second
one
is
a
rack
asset,
it's
also
under
apps
v1,
and
what
it
does
is
that
it's
actually
an
implementation
details
of
deployments.
So
you
don't
really
need
to
create
that
or
use
that
it's
just
something
that
deployments
create
to
to
have
the
replica
set
controllers
to
create
or
parts
and
that's
it,
and
it's
also
for
the
state,
less
work
clothes,
because
it's
part
of
the
deployment
and
implementation
detail-
and
there
is
also
replication
controller.
B
If
you
don't
know
what
it
is,
you
probably
don't
need
to
care
about
it,
because
it's
some
legacy
design
that
we
try
to
steer
people
away
from.
So
if
you
are
thinking
about
what
is
this
just
used
appointment
instead,
and
so
for
so
that's
all
for
Stella's
workloads,
but
you
still
need
something:
that's
stay
fo,
for
example
your
database,
your
cluster
applications,
then
your
need
you'll
need
your
paths
to
have
each
other
have
it's
on.
B
Maybe
it's
on
storage
or
its
own
identity
or
its
own
network
identity,
and
then
stay
for
set,
gives
you
that
so
you
can
waste
a
full
set.
You
can
deploy
a
number
of
I
similar
parts,
but
each
part
will
have
their
own
storage
and
then
they'll
have
their
own
network
identity,
and
it's
pretty
good
for
databases.
For
example,
we
have
seen
people
running
using
stateful
set
to
run
relays
or
toast
grass
in
production
with
with
a
full
set,
and
it's
also
GA
it's
under
apps
v1
and
then
there
is.
B
There
are
also
batch
jobs
that
you
want
to
run.
For
example,
you
want
to
do
some
batch
processing
you
want
to.
For
example,
I've
had
I
have
a
pile
of
emails
that
I
want
to
send
or
I
want
to
do.
Some
Big
Data
stuffs
I
want
to
do
some
batch
processing.
Then
you
can
use
job
to
do
that.
What
job
does
is
it
creates
a
bunch
of
parts
and
you
can.
B
Is
that
the
job
the
posit
job
creates
is
going
to
complete
it's
going
to
exit,
because
you
don't
want
your
web
like
web
applications
running
in
your
deployment
to
terminate
or
you
don't
want
your
database
in
stay
full
set
to
terminate,
but
for
job
you,
usually
you
want
a
job
to
finish
after
it's
done,
and
then
you
store
the
lot
somewhere
for
you
to
access
so
and
that's
a
big
difference
of
the
job
in
with
the
other
API.
So
job
is
under
patch.
V1
is
also
GA
and
then
there's
cron
job.
B
What's
the
difference
between
cron
job
and
job,
so
pong
job
allows
you
to
create
job
at
a
certain
time.
You
can
say
create
one
job
every
day
or
every
month,
and
that's
a
big
difference.
So
cron
job
is
under
patch
view
on
better
one
and
we're
going
to
make
a
ga
in
the
future
and
the
last
one
is
daemon
set,
so
demon
set
from
its
name.
It's
you
can
probably
guess
what
it
does
so
demon
set
is
an
API
that
allows
you
to
create
paths
running
on
every
single
node,
like
a
demon
on
each
node.
A
Say
yeah
I
would
say
we
have
this
controller
if
you've
ever
looked
at
the
internals
of
kubernetes
right.
The
job
controller
is
good.
At
one
thing,
it's
going
to
launch
a
bunch
of
pods
based
on
the
parallelism
of
the
job
and
based
on
their
statuses,
aggregate
it
and
say
the
jobs
complete
either
failed
or
successful
right.
A
So
in
theory
you
could
have
deployment
launch
pods
directly,
but
the
reason
deployment
uses
replicas
set
is
because
replica
set
is
good
at
producing
and
replicas
of
a
particular
pot
and
deployments
good
at
like
scaling
replica
sets
in
order
to
achieve
features
like
rolling
updates,
roll
forwards,
roll
backwards
and
so
forth.
We.
B
B
B
B
It
doesn't
need
to
go
through
the
default
scheduler,
and
what
default
scheduler
does
is
that
when
other
controllers,
like
deployment
or
a
stateful
say
with
when
they
create
parts-
and
they
are
not
going
to
know
where
the
pod
is
going
to
be
scheduled
on
so
the
default
scheduler
then
comes
in
and
look
at
the
pods
and
look
if
it's
scheduled
or
not.
If
it's
not
scheduled,
yet
it's
going
to
assign
a
node
that
has
enough
resource
to
let
the
pods
being
scheduled
there
and
then
Cuba
is
going
to
run
the
controller
of
that
pie.
B
What
that
means
is
that
so
for
now
the
the
point
and
we're
close
API
supports
the
rolling
update
feature.
The
deployment
that
stateful
said
demon
said
you
can
do
the
rolling
update.
What
that
means
is
that
you
can,
you
know
and
shut
down
one
instance,
one
part
at
a
time
and
bring
up
the
new
instance
one
at
a
time,
but
you
cannot
do
that.
You
know
across
failure
domain,
so
if
you,
if
I,
want
to
update
one
failure
domain
at
a
time,
I
cannot
do
that
easily.
Today.
B
I
need
to
maybe
create
multiple
deployments
or
say
for
say
across
different
fellow
domains
and
manage
that
individually.
So
we
are
proposing
this
idea
to
have
a
disruption
budget
for
each
fellow
domains,
and
then
we
can
say
I
can
only
tolerate
this
number
of
has
to
be
killed
within
this
fellow
domain
and
that
give
you
some
safeguards
against
your
filler
domains.
B
A
How
many
you
guys
use
stateful
sets
at
all
anybody?
Okay
and
you
use
those
staple
sets
with
persistent
vayan
claims
and
you
use
dynamic
provisioning
all
in
some
type
of
cloud
provider
or
in
your
well.
So
stateful
sets
got
this
thing
right.
We
don't
actually
respect
scheduling,
predicates
right.
So
if
you,
if
you
specify
a
nanny
affinity,
what
ends
up
happening
is
the
volume
provisioner
is
going
around
Rob
and
schedule
your
storage
across
zones-
and
you
say
I-
want
to
place
my
pot
here.
A
Well,
what
it
actually
is
gonna
do
is
place
your
pod,
where
you've
allocated
your
storage
for
most
clouds.
You
know
pd's
EBS
volumes,
their
zonal
resources
right.
So,
if
you're
trying
to
get
high
availability
by
getting
a
reasonable
distribution
across
zones,
you'll
get
it
I
mean
probabilistically,
because
we're
round-robin
across
phones
anyway,
but
you
can't
actually
specify
it
in
the
pot.
So
michelle
has
she's
a
member
of
six
storage,
has
kind
of
fixed
that
she's
integrated
volume,
provisioning
with
the
scheduler
so
prior
to
provisioning
in
the
ball.
A
It'll,
look
at
your
staple
set
or
look
at
your
pot
with
the
PVC
determine
what
your
scheduling
predicate
is
and
actually
schedule
your
volumes
in
an
appropriate
way
so
that
you'll
get
the
distribution.
You
asked
for
not
the
one
that
we
hard
coded
under
replication
check
for
pods,
so
anybody
running
elasticsearch
anybody
wearing
an
elastic
search
in
kubernetes.
A
Okay,
so
I
mean
you're,
probably
aware
that
if
you
try
to
run
it
in
a
staple
set
and
then
you
do,
a
rolling
update
requires
quite
a
bit
of
duct
tape
in
order
to
like
not
knock
the
pot
over
or
leave
the
cluster
on
your
replicated,
and
you
still
want
to
have
a
readiness
check.
You
don't
want
that
readiness
check
to
communicate
under
replication.
So
you
know
I
mean,
like
we
always
said
staple
set,
was
not
going
to
lose
going
to
be
bring
your
own.
A
Batteries
require
a
little
bit
of
duct
tape,
but
that's
just
too
much
duct
tape
and
it
kind
of
is
applicable
to
a
wider
range
of
distributed
systems.
So
we're
gonna,
try
to
add
an
under
replication
Shack
to
be
able
to
say.
Okay,
don't
knock
me
over
if
you
do
I'm
under
replicated,
but
I'm
am
ready
and
I
can
serve
traffic
and
that's
really
to
address
a
need
for
elastic,
search
and
specific,
but
a
broader
category
of
distributed
systems
in
general,
and
then
termination
reasons
signal
for
pods.
A
A
Your
pot
is
gonna,
come
back
and
get
rescheduled,
you
don't
want
to
reread
locate
your
storage
and
actually
it
have
to
do
it
twice,
because
you'll
have
to
read
repopulate
the
pod
when
it
comes
back
up
that
gets
super
expensive,
particularly
if
you're
spread
across
zones.
So
really
we
just
want
to
be
able
to
send
a
signal
to
the
pod
saying:
okay,
you're
being
terminated
for
scaling,
so
you're
not
coming
back,
or
at
least
the
operators
intention
is
that
you're
basically
being
decommissioned.
A
You
can
intercept
it
and
take
whatever
actions
are
necessary
to
appropriately
decommission
the
pot
and
we
replicate
the
storage
or
to
say:
okay,
you're
gonna
come
back
real
fast.
If
you
don't
it's
a
problem,
we
should
probably
block
the
role
in
update
anyway.
So
don't
do
anything
just
realize.
You're
gonna
die
go
over,
but
please
don't
beat
up
the
network
by
replicating
all
of
your
storage.
A
So
how
many
get,
how
many
people
in
the
audience
are
helm
users
a
lot
of
you?
Okay,
so
how
many
of
you
are
everyone's
own
helm
to
helm?
Three
is
not
really
our
thing
yet
so
helm
two
has
a
few
announcements.
The
2.9
release
is
out
newer.
One
at
stability
focus
mainly
bug
fixes
and
that's
pretty
much.
What
we're
gonna
do
with
2.9
going
forward.
Helm
3
is
probably
what
most
people
are
really
interested
in
hearing
about,
so
the
proposals
merged
they've
decided
in
broad
strokes.
A
What
helm
3
is
going
to
look
like
and
they've
started
building
it
tillers
gone
away,
so
there
is
no
server
side
component
at
this
point,
charge
should
be
updated
with
libraries
and
schema
ties,
values,
we've
added
a
notion
of
lifecycle
events
within
an
emitter
handler
model,
which
is
something
that's
fairly
interesting.
You
might
want
to
look
into
if
you're
interested
in
the
feed,
the
future
of
helm.
A
There
embedding
allow
scripting,
they're,
adding
to
CR
DS,
so
release
and
release
version
with
secret
resources
created
by
hooks,
will
now
be
managed
and
a
helmet
controller
projects
going
to
be
started
for
like
a
dev,
ops,
workflow.
So
kind
of
think
of,
like
a
get
flow
for
helm,
cross-platform
plugins
in
Lao
that
only
have
a
runtime
dependency
on
helm,
so
you're
not
locked
into
point
in
a
bunch
of
other
stuff
and
a
complimentary,
a
man
to
fetch
and
push
packages
to
a
repository
are
some
of
the
major
outlines
and
the
basic
status
is
right.
A
Now
it's
starting
implementations.
So
a
lot
of
these
are
open
issues.
A
lot
of
these
are
proposals.
If
you're
happy
with
the
direction,
that's
great,
if
you're
not
happy
with
the
direction
now's
a
good
time
to
chime
in
if
you
want
to
contribute
and
help
shape
the
direction
with
your
contributions
now
there's
great
time
to
get
involved.
It's
a
question.
A
So
the
discussion
is:
is
there
a
discussion
around
different
templating
options,
so
in
helm?
Two,
you
actually
can
replace
the
default
templating
option
with
their
own
templating
option.
It's
not
trivial,
but
if
you
wanted
to
do
it
as
possible
and
in
helm,
three
you'll
be
able
to
do
the
same
thing.
So
if
you
don't
want
to
use
the
default
templating
option,
you
could
bring
your
other
and
I
believe
they're
working
to
make
it
actually
a
little
bit
easier,
not
that
it's
like
insurmountable
hard
to
do
in
helm.
A
A
A
A
So,
if
the
hell,
if
the
absurd
e
has
good
utilization
and
is
journaling
ready,
Helms
community
said
they
want
to
adopt
it
and
integrator
to
have
applications
inside
of
helm,
but
the
axial
view
controller
and
the
AB
CRD
are
somewhat
orthogonal
helm.
Those
packages
at
CR
D
is
mainly
about
live
instances
of
applications.
Oh.
A
Go
ahead,
you
mean
to
go
back
which
mean
home
to
an
m3.
Now
that
I
actually
can't
answer
it.
I
would
have
to
get
one
of
the
helmers
around
I'm
sure
they're
going
to
allow
you
to
get
to
migrate,
your
charts
from
helm
to
to
helm
3,
but
I,
don't
know
how
like,
if
there's
you
know,
since
it's
not
built
yet
I.
Think
it's
in
everybody's
mind.
How
do
you
migrate,
I,
don't
think,
there's
formal
instructions
right,
ok,
I,
think
the
how
you
might
be
from
helm
to
the
helm.
B
So
for
trusting
the
apps
for
charts,
and
so
if
you
don't
know
what
chart
is
it's
a
like
a
package
of
the
home
of
the
kubernetes
apps
that
you
can
deploy
through
helm
and
we
have
a
the
charts
community
have
an
hour
meeting
every
other
Tuesday
and
there's
also
Cubase.
It's
a
website
for
web
UI
for
home
charts
and,
and
they
just
released
a
point.
Six,
oh
and
then
home
upgrade
is
also
supported.
A
So
we
talked
a
little
bit
about
the
application
CRT
we
opened
a
cap,
the
community
didn't
like
the
process
of
caps
in
general,
so
we
open
your
repo
and
we
opened
a
bunch
of
issues
and
we
started
working
the
repos
listed
on
the
slides
and
we're
looking
for
contributors
and
opinions
as
well
to
expand
a
little
bit
on
what
we
touched
on
the
application.
Crd
is
basically
a
way
to
aggregate
the
pods
staple
size
services.
Pvcs
persistent
volumes
in
such
a
way
that
you
can
identify
that
these
things
are
part
of
the
same
application.
A
What
so
composability
dependencies
and
the
exact
semantics
of
aggregation
are
still
somewhat
of
an
open
question
and
we're
looking
for
community
contributions,
even
if
you're
not
interested
in
contributing
code.
If
you're
just
interested
in
contributing
your
experience
and
what
works
for
you,
it
would
be
really
valuable,
because
that
allows
us
to
make
sure
we're
building
the
right
thing
and
then
what
we
build
as
a
notion
of
an
application
is
useful
for
you
and
that's
what
our
primary
focus
is.
A
So
we
don't
want
to
build
things
that
yeah
we
built
this
new
feature
nobody's
using
it,
because
it
doesn't
really
represent
an
application
in
any
way,
that's
meaningful
to
me
right.
So,
if
you're
looking
for
something
they
get
involved
in,
that's
like
as
an
intro
to
kubernetes
and
first
contributions,
it's
a
good
place
to
start.
A
If
you
were
to
look
at
them
in
a
UI
or
if
you
were
to
do
a
COO
because
I'll
get
the
application,
CRD
solves
those
problems,
it
doesn't
solve
the
installation
problems
and
it
doesn't
solve
the
packaging
problems.
Helm
is
a
good
package
manager
there,
it's
probably
the
most
dominant
one
in
the
community
right
now.
There
are
other
package
managers
out
there.
We
don't
want
to
go
resolve
that
we
don't
need
yet
one
more.
A
Well,
the
application
CRD
doesn't
have
a
notion
of
release.
Helms
notion
of
release
is
really
just
the
version
of
the
package.
That's
installed
with
the
updates,
I'm,
not
sure
like
what
I
don't
think
they
intend
to
change
the
wording,
but
I
mean
if
that's
feedback
that
you
have
I
would
definitely
go
to
that
helm.
Contributors
meet
up
and
just
say,
come
on.
A
So
we
all
like
to
say
that
the
gke
UI
team
is
actually
integrating
it
now
and
it's
probably
gonna
get
integrated
into
the
the
open-source
UI
as
well,
because
they're
adopting
the
dashboard
yeah.
So
what
it
ends
up
looking
like
is,
when
you
install
let's
say
my
wordpress
you'll
see
an
icon
for
WordPress,
and
then
you
open
that
up
and
you
see
a
tree
of
things
you
see
like
the
services
related
to
WordPress,
you
see
the
stateful
set
containing
the
MySQL
server.
A
A
D
D
A
For
sure
we
we
talked
to
the
helm
guys
on
a
regular
basis,
but
that
would
definitely
be
good
feedback
to
give
to
the
helm
guys.
It's
a
little
bit
lengthy
for
me
to
repeat
that
over
mic,
but
we're
recording
but
yeah
definitely
I
would
suggest
either
coming
to
the
hell
meeting
or
even
coming
to
say,
gaps
and
just
give
that
feedback.
There.
A
So
the
question
was:
is
it
in
scope
to
think
about
services
that
are
not
actually
being
hosted
in
cluster
when
talking
about
the
application
CRT?
And
the
answer
is
probably
maybe
so
I
mean
like
with
kubernetes?
It
brings
up
some
interesting
ideas
of
how
services
are
hosted
right,
like
you,
can
have
a
white
box
service
which
is
pretty
much
hosted
in
cluster.
A
You
can
have
a
black
box
service,
which
is
something
that
you
connect
to
like
a
relational
database,
that's
provided
by
a
cloud
provider
and
you
can
have
a
grey
box
service,
something
that's
hosted
in
cluster,
but
someone
else
who's
in
cluster
is
using
it
as
a
white/black
service.
I
think
kubernetes
supports
all
of
these,
and
we
talked
to
the
open
service
broker,
guys
a
lot
about
what
the
difference
between
a
service
and
I
don't
mean.
A
The
networking
primitive,
but
a
service
that
we
traditionally
think
of
as
engineers
and
services
is
an
application
and
how
the
application
CRD
should
interact
with
OSB
I
think
the
open
service
broker
and
their
notion
of
provisioning
and
services
is
kind
of
like
the
community
standard,
going
forward
with
how
to
interface
services.
With
your
cluster,
how
applications
and
services
interact
is
an
open
area
of
discussion.
That
is,
we
would
definitely
like
to
have
you
back
on.
B
So
this
is
our
last
tie
and
we
also
care
about
other
ecosystem
projects,
for
example
compose
which
is
quite
popular
sub-project
undersea
gaps.
What
it
does
is
that
it
translate
a
docker
compose
file
into
kubernetes
resource
file,
and
then
we
have
monocular
it's
a
web
UI
for
helm,
chart
repos
and
chart
museum,
it's
a
home
to
our
repo,
with
the
support
of
Amazon,
s3
and
Google,
Cloud
storage
and
catch.
It's
a
way
to
declaratively,
define
and
deploy
your
applications
and
then
Mehta
controller.
B
It's
a
framework
for
you
to
write
a
custom
controller
without
you
know,
knowing
a
lot
of
details
about
how
to
write
a
controller,
you
just
implement
a
logic
and
you'll
fit
it
to
made
a
controller,
and
you
can
write
it
in
any
language.
You
want
JavaScript
Python
and
you
can
fit
it
to
made
a
controller
and
you
will
run
the
control
loop
for
you.
So.
A
A
It's
something
that,
if
you
haven't
seen
you
might
want
to
check
out
draft,
makes
it
easy
to
build
and
compose
applications
in
kubernetes
scaffolds
a
new
one.
This
is
out
of
google
and
it
facilitates
continuous
development
for
kubernetes
applications.
They
recently
presented
a
pig
and
sig
apps,
and
some
of
their
members
have
been
very
active
recently
in
Missy
gaps.
Community
and
crew.
Bliss
is
like
a
native
serverless
platform
and
we've
got
a
lot
more
there's
many
many
more
things
in
the
ecosystem
that
are
part
of
sig
apps.
A
A
There's
a
lot
of
different
ways:
you
can
contribute,
so
you
can
start
with
the
weekly
meetings.
That's
a
good
way
to
get
to
know
everybody
and
just
like,
come
in
and
see
what's
going
on
if
you're
more
comfortable,
like
just
taking
on
an
issue
and
opening
an
issue,
you
can
go
to
our
landing
page,
look
at
any
of
the
projects
and
start
contributing
code,
we're
always
looking
for
contributions
both
for
bug,
fixes
for
new
features
and
for
documentation.
So
all
of
those
are
good
ways
to
get
involved.
If
you're
looking
to
get
involved.
B
A
A
I
mean
it's
something,
so
it's
something
we
haven't
actively
put
on
the
roadmap
to
go,
do,
but
it
yeah
it
like.
She
said
we're,
definitely
aware
of
it.
If
it's
something
you
would
be
interested
in
contributing.
That
would
be
awesome
like
it's,
not
something
that,
like
I,
think
you
would
get
a
lot
of
pushback
on
like
hey.
We
want.
We
don't
want
this
to
happen.
It's
just
not
been
on
the
highest
tier
of
priority.
A
So
that's
so
the
question
was
with
any
containers
and
with
pod
restart
policy.
Basically
you're
not
going
to
rerun
your
any
containers
unless
you
get
a
pottery
stock
and
the
behavior
you
were
looking
for
is
to
have
the
any
containers
run
on
container
restart,
so
the
behavior
is
you're.
Looking
for
more
flexibility
in
that
behavior
and
the
actual
question
is:
is
cig
apps
for
signor
the
right
place
to
ask
that
question
and
I
would
say
the
answer
to
that?
Is
yes,
like
that's
that's
one
of
those
overarching
questions.
A
It's
gonna
have
to
be
a
collaboration
between
say,
gas
and
cig
node,
and
if
there
was
disagreement
there
under
new
governance,
we
would
probably
kick
that
up.
The
cigarette
texture
and
but
I
mean,
like
generally,
if
cig
absence
signal,
agree
that
okay,
this
is
the
right
thing.
We
should
do
it.
The
only
thing
I
would
say
offhand
is
that,
like
they're,
given
that
pot
is
v1,
there'd
have
to
be
a
somewhat
compelling
reason
to
do
it
as
opposed
to
just
swell
it's
a
nice
thing
to
do.