►
From YouTube: Kubernetes SIG Apps 20210614
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
Welcome
to
the
monday
june
14th
2021
kubernetes
sig
apps
meeting.
If
you
don't
already,
have
it
open,
I'm
dropping
the
agenda
into
chat
here
so
that
you
can
get
to
the
agenda.
We
have
a
couple
items
already
up
there.
If
you
have
something
else
that
you
wanted
to
talk
about
today,
please
feel
free
to
add
it
in
the
discussion
section
after
the
two
items
we
already
have,
there
is
one
announcement
that
is
not
listed
there.
A
I
wanted
to
share
that
after
five
or
six
years
more
than
five
years
of
sharing
kubernetes
sig
apps,
I
mafrina
I'm
going
to
step
down
from
that
position.
We
have
three
very
capable
other
chairs
who
can
continue
to
wrangle
this,
but
I
have
not
had
much
time
as
of
late
and
so
it's
better
to
leave
it
in
the
hands
of
people
who
have
the
time
and
they
know
what
they're
doing
so.
This
is
me.
A
B
I
would
like
to
thank
you
matt
for
for
bringing
first
of
all
for
bringing
in
sig
apps
into
prediction,
because
I'm
not
sure
if
people
are
aware,
but
was
actually
one
of
the
initiators
of
sig
apps
back
in
the
in
the
early
days
of
kubernetes.
So
thank
you
very
much
for
for
creating
sync
apps,
which
is
this
amazing
group
of
people,
and
thank
you
very
much
for
leading,
say,
gaps
with
example,
with
your
thoughtful
words
with
advice
over
the
past
years,.
A
A
Thank
you
so
with
that,
I
believe
we
have
a
demo
first
of
dev
file.
Do
we
have
somebody
on
who
is
gonna
present
that.
C
Yes,
hello,
matt,
I'm
mario
riedo
from
red
hat
and
I'm
here
with
eda
and
andreas
from
aws.
I'm
gonna
share
my
screen
to
so
I
have
a
presentation
to
show
so
before
I
actually
go
through
the
demo.
We
have
some
slides.
C
C
C
Okay,
yeah,
so
I'm
going
to
so
we're
going
to
to
present
that
file
and
the
the
reason
we
are
here
actually
is
because
we
we
want
to
propose
the
dev
file.
That
is
a
file
specification
as
a
sandbox
project,
cncf
sandbox
project.
C
So
we
we
wanted
to
get
some
feedback
before
actually
submitting
the
proposal,
so
I'm
going
to
start
with
the
agenda
and
so
we'll
get
through
we're
going
to
go
into
like
the
motivation
why
we
are
doing
that
with
some
specification,
so
how
we
are
actually
doing
the
specification
of
this
this
file
and
then
we're
going
to
show
some
similar
projects,
the
default
registry
and
then
two
brief
demos
of
two
tools
that
leverage
that
file
today
and
then
we'll
do
some
conclusion
with
our
roadmap
and
the
what
we
think
we
need
to
do
for
to
submit
the
dev
file
as
a
sandbox
project.
C
So
an
I'm
here
with,
as
I
said,
with
either
andreas.
That
will
help
me
with
with
that
presentation.
So,
let's
start
with
the
motivation.
So
what
actually
is
the
problem?
So
problem
is,
developers
should
spend
their
time
coding,
but
with
the
rise
of
microservices
cloud
applications,
and
even
before
that,
so
the
problem
is
that
we
spend
a
lot
of
time,
configuring,
our
development
environment.
C
We
have
trouble
to
replicate
problems
that
happen
in
production
because
we
were
not
able
to
have
a
development
environment
that
is,
that
is
identical
to
the
production
one.
C
We
are
slowing
productivity
because
often
since
we're
not
able
to
build
both
tests
properly
on
our
ide,
we
we
use
like
the
ci
or
some
external
services,
and
we
need
to
wait
the
the
feedback
for
from
that.
So
these
are
problems,
and
maybe
either
do
you
want
to
add
something
to
that.
D
Yeah,
my
name
is
ida
and
I
work
as
a
product
manager
within
aws
and
their
developer
tools,
department
and
and
when,
when
we
go
and
talk
to
developers
and
gather
feedback
on
on
what?
How
can
we
help
out
and
be
better?
What
pain
points
can
we
solve
for,
and
the
development
pain
point
still
comes
back
to
how
difficult
and
cumbersome
it
is
to
get
a
proper
environment
up
and
running.
So,
if
not
partner,
it
can
even
be
most
of
the
time
that
the
developers
spend
just
managing
their
dependencies
or
their
depth
tools.
D
So
that's
what
we
are
like
the
motivation
for
us
and
our
interest
in
joining
the
collaboration
around
the
deaf
people
has
really
been
to
figure
out
how
we
can
address
these
pain.
Points
of
you
know,
spending
time
the
right
place,
which
should
be
coding
and
not
on
on
getting
set
up
or
worrying
whether
or
not
you
have
the
same
environment
as
your
teammates,
because
that
not
it
doesn't
just
slow
down
you
as
an
individual
but
the
whole
team.
If
everybody
has
these
hard-earned
environments
that
are
hopefully
identical,
but
not
always
exact
matches.
C
So
the
the
ideal,
the
ideal
development
environment,
which
should
be
simple,
so
you
should
be
able
to
create
that
as
a
with
a
click
with
just
clicking
on
a
button,
and
it
should
be
reproducible
so
that
when
a
new
developer
comes
on
the
team,
he
will
be
able
to
produce
it
right
away
and
it
should
be
fast.
So
we
should
be
able
to
to
get
a
feedback
early
when
we
are
developing.
D
And
that's
very
much
in
line
with
with
what
we
hear
when
we're
out
from
awsi
to
talk
with
developers.
Is
that
since
it's
so
difficult
today,
what
would
the
ideal
be?
And
that
is
the
the
ease
of
creation
that
you
would
have
the
the
notion
of
of
easily
sharing
an
environment
with
your
teammates
and
having
sort
of
a
good
insurance
that
it's
an
identical
environment
to
what
you
have
over
in
the
cicd
product
process
line
and
then
also
just
that.
D
C
So
what
if
there
was
a
simple
vendor
neutral
standard
to
specify
repeatable
fast
development
environments,
so
one
a
file
specification
that
allow
that
is
really
specialized
in
development
environments.
C
So
that's
the
what
we
wanted
to
do
with
the
dev
file,
and
this
is
how
that
file
looks
like
so
these
are
different,
the
at
eye
level,
the
different
sections
of
that
file.
This
is
a
so
it's
a
iml
file
and
it
has
a
first
section
where
we
version
the
api
so
that
clients
can
tell
exactly
what
version
of
the
api
they
are
using.
C
And
then
there
are
those
three
main
fields:
those
sections
the
first
one
is
components,
so
components
are
containers
or
other
resources
like
volumes
or
any
kubernetes
resource,
and
that
is
used
in
the
development
environment
to
build
to
test
debug
the
application.
C
And
then
there
are
some
comments
that
are
associated
to
the
components
and
those
common
commands
are
usually
the
comments
that
you
have
in
in
an
ide
where
you
have
a
command
that
will
let
you
build
the
application
or
run
it
or
like
start
a
database,
etc
and
last
the
last
section
are
events.
Those
events
are
related
to
the
life
cycle
of
the
development
environment.
C
So
when
you
start
your
development
environment,
you
may
want
to
pre-build
your
application
or
even
run
it
so
that
you're
able
to
test
one
pull
request
that
somebody
did
with
just
starting
your
development
environment
and
checking
out
the
branch
of
the
request
you
you
can
just
build
and
start
the
application
right
away.
If
you
have
that
in
the
in
the
events
section.
C
So
if
you
have
the
comment,
the
build
common
in
the
post
start
build
and
run
comment
in
the
past
start
the
events,
so
that's
basically
it
for
at
the
eye
level.
There
are
more
details
than
that,
but
I
don't
think
it's
really
useful
for
this
short
demo,
and
but
the
important
thing
is
that
taught
about
the
depth
file
as
a
file
that
should
be
versioned
with
the
application
with
the
source
code.
C
So
you
should
put
it
in
the
in
the
git
repository
so
that
when
the
tools
are
checking,
when
you
check
out
the
the
your
application,
you
will
be
able
to
also
to
start
your
development
environment.
C
Let's
say
so.
There
are.
Those
are
like
similar
formats
that
already
exist,
so
eda
will
let
you
present
those.
D
Yeah,
I
won't
bother
going
into
the
details
of
each
of
one
that
we
have
listed
here.
It's
just
to
show
that
that
we
have
a
lot
of
what
I
would
call
sprawl
in
the
market
right
now.
There
are
different
attempts
of
a
dockerized
development
environment,
but
they're
all
slightly
variants
of
the
same
theme.
So
what
we
are
really
looking
forward
to
working
on
the
dev
file
is
to
create
this
like
an
open
standard.
D
That's
really
com
compatible
with
whatever
is
on
the
market
today,
so
whether
you're
using
a
git,
pod,
yaml
or
a
dev
container
json.
You
should
be
able
to
just
rely
on
the
fact
that
it
can
be
compatible
with
the
dev
file
and
that
you
can
get
this
sort
of
code,
ready
environment
up
and
running
that
just
understands
exactly
what
kind
of
tooling
you
have
specified
alongside
the
source
code.
In
your
repository.
C
So
we're
coming
to
the
last
part
of
this
introduction
and
that's
about
the
default
registry.
That's
something
that
we
are
currently
working
on:
that's
not
yet
available,
but
the
the
goal.
So
the
idea
for
us
is
to
have
a
catalog
of
dev
files
available
online
so
that
so,
if
somebody
want
to
get
started
with
a
java
project
or
go
project,
we
we
can
provide.
C
We
have
a
catalog
of
of
that
file
that
should
be
contributed
by
the
community,
so
yeah,
those
those
should
be
would
be
community
community
develops.
C
So
I
think
that's
it
for
the
introduction.
So
now
we're
gonna
show
a
couple
of
demos,
so
I
will
start
with
the
dev
workspace
kubernetes
operator,
so
the
cube
so
as
as
the
name
shows
it's
it's
a
kubernetes
operator.
So
that
means
that
the
dev
workspace
is
an
extension
of
the
kubernetes
api
and
a
kubernetes
controller.
C
So
for
the
api
I'm
going
to
that's
to,
I
have
a
cluster
kubernetes
cluster
here
where
I've
deployed
the
dev
workspace
operator.
So
if
I
do
a
cube,
ctl
explain
dev
space
here.
C
It
should
show
me
the
some
documentation
of
of
that
api
because
that's
I've
deployed
the
crd
here
and
those
are
all
kubernetes
objects
that
are
reconciled
by
the
controller
to
configure
development
environment.
So
how
does
that
relate
with
the
dev
file?
So
this
is
a
kubernetes
api.
How
does
that
relate
to
the
dev
file,
so
the
dev
workspace
is
actually
as
actually
so.
The
network
space
object
kubernetes
object
as
a
def
file
in
it.
C
So
if
I
do
the
same
so
that
the
rene
cube
ctl,
explain
that
workspace
and
I
go
and
spec
template.
C
I
will
see
that
the
fields
here
so
the
comments,
field
or
components,
field
events
field.
There
are
other
fields
that
are
other
details
of
the
def
file,
but
those
are
actually
the
section
of
the
dev
file.
C
So
what
we
do
is
that
we
are
creating
automatically
from
the
dev
file.
That
is
a
file
specification.
We
create
a
kubernetes
api
so
to
be
able
to
create
from
a
dev
file
to
create
a
kubernetes
object
and
that
object
will
actually
power
development
environments.
So
and
if
you
wonder
what
what
does
that
mean?
What's
the
development
environment,
so
I
can
show
you
because
I
have.
I
should
have
a
web
workspace
here
in
my
cluster
and
it's
running
and
I
have
a
link
to
that.
C
So
if
I
click
here,
there
is
an
ide
that
will
open
that
id
is
actually
running
in
a
container
and
it's
a
sidecar
of
the
dev
file
component
of
my
project
yeah.
Now
it's
it's
open
and
I
see
it
so
I
have
my
source
code
here
and
in
the
source
code.
I
have
a
dev
file,
so
there's
that's
just
a
sample
sprint
clinic
fork
that
is
available
here,
and
that
has
a
a
def
file
here.
C
So
that
file
has
one
one
component
that
is,
is
using
a
maven
maven
container
that
allows
me
to
do
build
to
build
and
run
my
application
and
the
the
that
workspace
as
added
as
a
sidecar,
an
ide
application
that
allows
me
to
access
the
source
code
and
clone
the
source
code
from
from
my
ide.
C
But
basically,
then
I
will
be
able
to
to
do
java
coding
and
to
use
the
command
palette.
So
I'm
using
a
tia
that
is
an
ide
that
runs
in
your
browser
and
similar
to
visual
code,
but
that's
one
example
of
an
id.
It
can
be
changed,
so
it's
just
running
in
a
sidecar
container.
It
can
be
configured
to
be
another
ide
and
if
I
see
the
list
of
tasks
that
I
have
here,
I've
built
and
run
tasks
that
were
defined
in
my
dev
file.
C
So
and
if
I
do
build,
for
example,
it
will
run
the
build
for
me.
So
I
the
build
is
the
command
to
build.
The
application
is
defined
in
the
dev
file.
That
is,
is
actually
here,
so
that's
actually
the
the
the
command
and
then
I
have
a
command
to
run.
So
I
can
share
that
the
def
file
and
with
my
team
and
they
will
be
able
to
build,
run
the
bug,
the
application
with
that.
C
So
that's
it
for
my
demo,
so
we'll,
let's
now
andrea,
so
we'll
stop
sharing
and
let
andreas
do
his
demo
for
the
lab
runner.
E
Thank
you.
Can
you
see
my
screen.
E
How
do
I
do
we
know
where
I
can
click
or.
E
E
C
Either
warning
in
in
chrome,
so
I
had
to
accept
in
order
to
be
able
to
share
the
screen.
A
E
Unfortunately,
not
I
see,
pause
and
stop
recording
which
I'm
assuming
you
won't
do
that.
A
No,
I
look
in
the
where
you
see
the
participants
and
chat
and.
E
No,
it's
it's
not
the
error.
Maybe
I
need
to.
A
A
I
do
have
a
comment
you
said
you're
going
for
cncf
sandbox.
If
you
land
in
the
sandbox
one
place
that
you
could
have
people
share
their
dev
files
through
and
make
them
discoverable
is
the
artifact
hub.
It
would
have
to
wait
until
it
actually
made
it
into
the
sandbox,
but
that's
one
place
you
might
want
to
go.
Look
to
make
them
discoverable.
After
the
fact.
A
If
you
go
to
artifacthub.io,
you
can
learn
about
it
and
and
see
what's
up
there
now
and
in
order
to
be
listed
in
the
artifact
hub,
something
has
to
be
through
an
open
source
foundation,
so
once
it
lands
in
the
cncf
as
any
kind
of
project,
then
artifacts
can
be
there
and
you
can
find
things
like
tekton
tasks
in
there
stuff
like
that,
and
so
you
can
see
examples
of
the
kinds
of
things
there.
All
the
code
is
open
source
and
on
github
and
there's
a
link
to
the
project.
There.
G
A
E
Okay,
thank
you
sorry
for
for
that.
So
my
name
is
andreas
rasius,
I'm
from
aws
similar
with
with
eda.
I
we
work
to
to
together
and
part
of
our
work
is
related
to
the
dev
file
format
and
similar
to
what
mario
showcase
we
also
have
the
the
dev
runner,
which
is
a
different
runner
for
that's
using
dev
files,
but
instead
of
the
kubernetes
is
using
docker
as
its
backend,
and
today
I'm
gonna
showcase
you
what
what
we
have
so
so
far
for
for
it.
E
So
the
the
dev
file,
div
runner,
is
actually
a
docker
cli
plugin,
so
which
allows
you
to
kind
of
create
dev
environments
using
like
the
the
definition
stored
in
your
your
source
code.
So
if
I
do
docker
help
as
part
of
the
the
output.
E
I
we
we
have
now
similar
to
how
we
have
compose
or
build
x,
or
a
scan
scan,
there's
also
a
devem
which
is
a
plugin
for
containerized
development
environments,
and
this
one
can
be
can
be
used
similar
to
docker
compose
so.
E
It
we
envision
it
to
have
like
some
some
simple
commands,
so
it
allows
you
to
start
and
stop
via
the
up
and
down
commands.
E
It
also
allows
you
to
infer
the
definition
from
a
certain
project,
so
in
case
customers
don't
have
a
definition.
We
can
suggest
one
for
for
them
and
we
also
allow
a
conversion
between
different
formats
to
to
the
the
file,
so
that
customers,
who
have,
for
example,
a
gitpod
yaml
or
a
dev
container
json,
can
can
use
it.
So
the
for
today,
I'm
going
to
showcase
how
like
we
can
start
a
dev
environment
for
a
simple
hello
world,
go
project
and
attach
the
the
id
to
it,
which
in
our
case,
will
be
vs
code.
E
E
To
to
attach
to
to
attach
to
to
the
container
so
once
the
the
id
is
attached
I'll
have
all
the
functionality
that
I
did
before.
But
in
contrast
to
what
mario
showed
vs
code
doesn't
use
a
sidecar
but
injects
itself
within
the
container.
So
it's
running
as
a
separate
process
within
the
the
container.
So
this
allows
it
to
kind
of
like
reuse,
all
the
plug-in
capabilities
that
it
previously
had.
So
like
language
servers
and
everything
will
work
out
of
the
out
of
the
box.
As
we'll
we'll
see
in
a
minute.
E
So
now
I
I
have
like
the
the
standard,
the
the
standard
hello
world
for
for
go,
I
mean
my
source
code.
I
have
have
my
terminal,
I
can.
I
have
the
tools,
so
I
can.
E
So
another
functionality
that
that
we
we
currently
we
currently
are
working
on
is
the
the
ability
to
to
infer.
So
again,
let's
say
I
have
like
a
standard
even
even
project
but
notice
that
I
hear
I
don't
have
the
the
dev
file,
but
using
the
the
dev
runner,
I
can
like
infer
the
suitable
dev
file
which
in
this
case,
because
I
had
like
a
pom
xml
file.
The
devrunner
suggested
me
a
java
type
image.
So
here
we
go.
E
To
start
my
my
environment,
so
now
I
can
go
go
back
to
to
work,
so
this
is
all
in
in
early
early
phases.
So
it's
not
yet
open
source,
but
we
are
planning
to
do
that
in
the
couple
in
the
next
couple
of
months,
working
together
with
the
devfile
community.
C
Yes,
I
will,
I
will
share
the
screen
again
and
you
should
be
able
to
see
it.
So
I
have
a
couple
of
slides
just
to
yeah.
That
was
the
aws
devrunner
demo,
and
so
this
is
used
by
older
tools
as
well,
so
eclipse
j.
So
and
I'm
I
I
work.
I've
been
working
on
eclipse
shift
for
the
last
five
years
and
we
are
we've
been
the
first
one
using
the
dev
file
and
we
are
yeah
using
it
to
define
the
development
environments.
C
The
the
roadmap
so
won't
go
into
the
details
here,
but
as
mentioned
that
file
registry,
we
want
an
online
services
service
that
tools
that
know
how
to
use
and
use
the
the
dev
file
will
be
able
to
leverage.
C
And
then
we
want
to
have
a
better
outlook,
support
that
means
to
be
able
to
specify
components
using
docker
file
or
compose
file
or
elm
charts
so
that
to
be
able
to
reference
those
artifacts,
those
different
types
of
artifacts
from
a
dev
file,
so
that
we
can
include
those
in
the
development
environment
and
then
yeah.
There
is
a
as
andreas
mentioned,
open
source
of
the
dev
runner
and
then
eclipse
chair
that
is
currently
using
the
version.
C
One
of
the
the
file
specification
are
is
going
to
move
to
the
version
two
in
the
next
month
and
then
yeah.
There
is
the
cncf
submission
we,
we
have
created
a
new
logo.
We
are
in
the
process
of
relicensing
the
source
code
from
epl
to
apache,
and
then
there
is
a
redesign
of
the
dev
file
landing
page
the
file
or
io
and
yeah.
Then
we
will
have
those
done
we'll
fill
the
proposal
form
so
yeah.
C
If
you
have
any
questions
or
any
feedback
on
how
to
present
that,
so
that
we
have
more
chances
to
be
accepted
as
a
cncf
sandbox
project,
so
that
will
be
yeah
really
useful
for
us.
A
Well,
thank
you
for
coming
and
presenting.
I
look
forward
to
seeing
what
happens
here.
If
anybody
has
any
questions
or
follow-up,
you
can
see
their
names
in
the
list.
I
would
assume
you
can
reach
out
to
them.
Thank
you.
This
was
great.
I'm
curious
to
see
what
comes
of
this.
I
know
there,
as
you
pointed
out
earlier,
there
been
tries
at
this
kind
of
thing
before
and
I'm
curious
to
see
what
happens
here.
A
All
right,
the
next
thing
we
have
on
the
agenda
is
washing
the
conformance
testing
dishes.
Did
we
have
somebody
who
wanted
to
talk
to
this.
H
Yes,
thank
you
aryan
speaking,
I'm
from
iii
we've
been
cleaning,
our
conformance
testing
and
we've
just
about.
H
Apps
endpoints,
we
created
three
more
e2e
tests.
They
follow
exactly
the
same
pattern
that
we
have
in
other
other
conformances
already
merged
so
and
they
have
been
reviewed
already.
So
we
would
just
appreciate
if
we
can
get
an
approve
on
those,
so
we
can
get
them
on
the
taste
with
anybody
that
have
the
ability
to
approve
will
really
appreciate,
and
then
we
can
get
it
in
this
release.
H
A
A
D
H
Yet,
if
there's
anybody
that
want
to
reach
out
and
tell
us
a
little
about
ontario
revision,
it's
a
family
of
seven.
H
A
All
right:
well,
I
think
ken
is
on
and
mache
and
janet,
and
they
usually
have
pretty
good
coverage
over
this.
So
we'll
go.
Take
a
look.
Thank
you.
H
Thank
you.
I
really
appreciate
your
support
and
I'll
report
back
in
your
meeting.
As
soon
as
I
got,
I've
got
10
other
endpoints
already
waiting.
It's
the
conformance
promotions
is
ready.
I'm
taking
you
there
to
seek
apps
meeting
tomorrow
so
by
tomorrow.
You'll
have
10
more
conformant
end
points,
and
these
just
need
to
do
their
two
weeks
on
the
test
grid
and
then
you've
got
seven
more.
A
A
All
right,
it
doesn't
sound
like
we
have
anything
else.
So
thank
you.
Everyone
for
coming.
You
can
get
a
little
more
than
20
minutes
back
of
your
meeting.
Time
have
a
wonderful
week
and
we'll
be
back
here
in
a
couple
of
weeks
thanks.
Everyone.