►
From YouTube: Developer Experience Office Hours: Simplifying and Standardizing Developer Environments
Description
Join OpenShift's Developer Experience experts for our regularly scheduled program filled with cloud native, Kubernetes, and OpenShift tips and tricks for developers.
A
A
A
A
Good
morning,
good
afternoon,
good
evening,
wherever
you're
hailing
from
welcome
to
the
developer
experience
office
hours
today,
we're
going
to
be
talking
about
simplifying
and
standardizing
developer
environments,
and
I
have
a
wonderful
cast
of
characters
here.
Stefan
lemire,
please
introduce
yourself.
Let
us
know
what
you
do
here
at
red
hat
and
and
then
you
know,
yeah
thanks.
B
Please
could
you
introduce
yourself
hello.
A
B
A
B
Yeah
exactly
and
that's
exactly
what
it
is
about.
It's
you
know
that
it
is
a
challenge
to
manage
the
develop,
the
different
developer
environments
that
you
have
there's
a
lot
of
different
pain
points
and
we
are
hearing
most
of
the
time,
the
same
things
from
all
the
developers.
Oh,
I
need
to
configure
my
developer
environment.
I
need
to
pull
all
the
dependencies.
B
A
B
C
You
don't
see
my
just
one
sec.
Let
me
try
taking.
A
I
need
like
a
sound
effect
bobby,
I
know
you're
listening.
It
would
be
funny
to
have
a
screen
sharing
disaster.
Sound
effect.
B
Thank
you
yeah
so
has
chris
mentioned.
We
are
going
to
to
speak
about
simplification
and
standardization
of
developer
environments,
but
I
think
more
precisely.
We
are
going
to
speak
about
developer
environments
that
are
codified
and
repeatable.
B
B
That
could
be
managing
the
configuration
overhead
of
working
in
cloud
native
applications.
So
you
have
smaller
services
and
you
want
to
to
switch
from
one
services
to
another
one.
You
want
to
troubleshoot
that,
so
you
want
to
con
to
see
how
all
of
those
services
are
connecting
all
together
and
there's
a
lot
of
configuration
pitfalls
in
order
to
to
repeat
that
environment
on
your
local
environment
and
there's
also.
B
So
if
we
can
go
to
the
next
slide,
please.
So
our
mission
is
really
about
simplification,
simplifying
all
of
this
and
accelerating
the
developer,
workflows
and
also
instill
consistent
standards,
so
that
it
helps
the
developers
to
work
with
their
projects
and
to
switch
from
one
application
component
to
another
one
and
make
sure
that
they
are
using
exactly
the
same
tools
all
together.
B
So
next
slide,
please
we
and
it's
okay,
yeah!
So
so,
basically,
what
we
are
trying
to
to
to
do
with
with
the
file
and
codified
developer
environment
is
to
bring
simplicity
in
the
sense
that
we
want
to
allow
a
developer
to
be
able
to
code,
build
tests,
run
and
debug
without
feeling
any
configuration,
pain
and
still
having
the
ability
to
use
the
favorite
tools
could
be
a
cli
tool
could
be
an
ide.
It
could
be
different
plugins
for
different
tools.
B
So
if
we
go
to
the
next
slide,
please-
and
today
we
know
that
when
we
develop
our
code,
so
we
have
our
id
configured
and
then
we
need
to
compile
our
code.
We
need
to
build
it.
We
need
to
build
also
the
image
for
for
our
application,
and
then
we
might
mount
the
local
file
system
or
do
a
nursing
so
that
each
time
we
do
changes
into
the
source
code
it
gets
rebuilt,
and
then
we
can
see
the
changes
as
well
and
we
might
need
to
attach
a
debugger
at
some
point
as
well.
B
So
that's
a
lot
of
manual
steps,
there's
a
lot
of
configuration
that
is
required
to
do
that.
It's
taking
a
a
long
time,
if
it's
the
application
component,
that
you
are
working
on.
That's
easy
because
you
have
that
setup.
Basically,
but
if
it's
another
application
component
that
you
are
just
interacting
with
and
that
you
need
to
pull
on
your
local
environment
just
to
be
able
to
to
to
test
and
to
debug
it,
then
it's
it's,
but
all
the
steps.
B
Most
probably
someone
has
already
figured
this
out,
and
so
usually
what
you
do
is
that
you
share
that
on
a
wiki
page
or
you
share
that
into
instructions.
B
So
what
we
do
with
the
dev
file
like
slide,
please
elsan,
is
that
we
put
all
those
instructions
into
into
the
define
and
the
file
is
basically
a
file
and
its
format
will
have
the
the
ability
to
to
to
to
get
this
information
completely
codified.
The
file
is
going
to
leave
with
the
source
code
of
the
application.
So
this
way,
when
you
pull
the
source
code,
you
have
the
definition
of
the
developer
environment.
That
is
needed,
so
you
can
just
go
and
code.
B
So
all
those
steps
will
be
available
and
will
be
understood
by
the
tools
that
you
are
using,
so
that
make
it
completely
seamless
and
and
easy
to
leverage
in
your
favorite
tools.
Nice,
that's
a
little
bit
about
the
dev
file
and
elson.
If
you
can
go
to
the
next
slide
and
inside
of
this
file
and
inside
of
this
format,
we
basically
provide
a
way
to
describe
the
the
best
practices
for
the
end-to-end
application
development
of
your
project
or
your
application
components.
B
So
we
will
have
different
pieces
all
together.
So
we
will
have
the
information
for
the
inner
loop,
everything
that
is
going
to
help
you
to
to
build
your
source
code,
to
build
the
image
to
also
debug
your
source
code
and
run
it
as
well.
So
you
will
have
all
of
this
information
and
you
will
also
have
the
definition
of
the
outer
loop,
so
how
you
will
do
the
deployment
of
your
your
application
on
the
platform
such
as
kubernetes,
for
example.
B
So
if
we
can
go
to
the
next
slide,
please
elsan
so
for
the
developer
teams,
the
architects.
Basically,
what
they
will
do
is
that
they
will
define
the
standard
way
of
working
by
defining
and
writing
the
def
file.
This
way
they
can
define
exactly
what
are
the
tools
and
what
are
the
different
components
that
are
needed
in
order
to
to
work
on
a
particular
stack
could
be
a
quarkus
stack,
for
example.
So
what
is
the
the
version
of
parcels
that
I
want
to
use?
B
What
are
the
images
that
I
want
to
use
to
do
that?
And
what
are
the
tools
as
well?
You
might
have
starter
projects
which
will
help
the
the
developers
to
get
start
and
to
have
a
sample
component
that
they
can
use
to
kick
off
building
their
new
application
component,
and
you
can
also
instill
some
compliance
policies.
B
So
for
the
developer
teams,
that's
getting
a
little
bit
easier
because
they
can
consume
the
define
in
their
tool
and
they
with
the
quaker
stack.
For
example,
they
will
be
ready
to
develop
instantly
because
they
will
have
all
the
tools
that
they
need
to
to
start
coding
and
they
will
have
a
guided
onboarding
experience
as
well,
so
they
know
how
they
can
build,
how
they
can
run
their
source
code,
but
they
will
also
be
able
to
leverage
the
starter
project
as
well.
B
B
So
next
slide,
please
because
the
way
we
we
do,
that
is
that
the
dev
file
into
all
the
tools
that
we
are
building
within
within
our
our
group.
B
We
use
the
files
as
a
common
layer
that
is
serving
all
the
different
tools.
So
if
you
have
a
def
file
for
your
project,
you
can
use
that
inside
of
the
openshift
developer
console
you
can
use
that
with
odo,
which
is
the
cli
for
developers
for
for
openshift
and
into
all
the
ide
that
we
are
building
in
the
plugins
for
the
ide
that
we
have
as
well.
B
C
A
defy
registry
is
a
centralized
place
to
store
that
files
that
tools
and
developers
can
easily
access
to
it's
an
oci-based
registry
with
some
rest
api
that
we
have
sitting
on
top
of
it
that
allows
people
to
access
their
content,
for
example,
getting
the
list
of
available
that
files
and
downloading
the
content
of
stack
as
well.
We
also
have
a
google
library
to
interact
with
as
well
in
case
you
want
to
do
it
programmatically.
C
So
there
are
different
types
of
registry
like
public
vendor
specific
and
clusters.
That
will
talk
about
a
little
bit
more
on
the
next
slide.
C
A
C
C
Users
can
also
have
have
to
install
their
own
custom
registry
in
their.
You
know
in
their
cluster
as
well
to
so
to
host
their
own
set
of
net
files.
It
can
be
used
by,
for
example,
a
company
to
store
a
list
of
dev
files
that
can
be
used
by
data
developers
to
develop
the
applications
within
the
organization.
C
B
C
Exact
same
way,
so
that's
the
beauty
of
that.
Like
you
know,
you
can
have
your
own
custom
ones
or
you
can
just
use
the
ready
to
be
made
from
the
committee
one.
So
everything
will
just
work
from
the
tools
perspective
awesome,
so
we
have
talked
about
what
that
files
are
and
who
use
and
benefit
from
them,
and
what
that
file
registry
is
it's
time
to
obviously
see
some
demos.
So
we
have
two
demos
today
one
is
on
that
file
with
audio
and
the
other
is
that
file
with
that
workspace
cool.
A
C
Okay,
so
this
demo
shows
how
that
file
helps
developers
easily
using
audio
cli
as
an
example
tool.
It's
just
a
tool
that
I
pick
happens
to
have
that
file
support
in
there
as
part
of
the
setup.
I
have
already
done
nosy
locking
to
log
into
my
cluster
before
let's
say
now,
I
want
to
create
a
brand
new
node.js
application
with
that
file
to
run
on
a
cluster.
To
do
that,
I
need
to
create
an
audio
component.
C
C
So
what
it
does,
is
you
take
a
look
at
what's
currently
here
it
basically
fetched
from
the
public
community
repository
that
I
talk
about
briefly
and
then
getting
the
list
of
available
dev
files
that
can
be
used
regularly
be
used
once
I
notice
there's
actually
a
nuke
js
stack
available.
So
let's
create
one
with
using
a
node.js
example.
C
So
do
audio
create
node.js
is
oops
typo
in
there
js
created
and
node.js
is
the
type
that
I
see
on
the
list.
That's
the
component
type
that
I
want
to
create.
I
want
to
give
the
name
just
a
random
name
that
I
give
it
to
you.
I
push
a,
I
also
add
a
starter
flat
in
there,
which
indicates
that
I
start
from
nothing
and
I
want
to
just
create
a
a
component
with
a
sample
application
in
there.
C
So
if
I
do
that,
you
create
that,
if
I
just
take
a
look
at
what
has
been
created,
it's
a
really
simple
noke.js
example,
because
it's
not
a
project,
you
can
see
a
service.js
file
in
there
and
there's
a
default
yaml.
C
C
So
in
the
dev
file
you
can
find
the
metadata
associated
with
that.
It
basically
tells
you
what
that
that
file
is
and
some
extra
information
associated
with
that
file,
and
you
can
find
the
container
component
to
define
what,
for
example,
what
images
to
be
used
by
the
tools
for
running
the
runtime,
what
the
images
can
be
used
for
doing
the
build
and
the
exposed
port
numbers,
for
example,
that
this
particular
container
is
exposing
a
certain
part
number
for
providing
the
noob
server.
So
it
will
be
that
information
is
there.
C
C
C
Knowledge
on
displays
at
all,
because
all
I
did
is
just
do
audio
create
and
I
do
audio
push
and
that's
it.
It
typically
takes
a
little
bit
faster
than
that
probably
doesn't
look
like
the
either
the
cluster
is
not
it's
a
little
bit
slow
on
this
side
today,
let's
wait
for
a
couple
of
seconds
for
that
yeah.
So
the
other
thing
is
you
notice,
there's
a
couple
of
starters
that
we
have.
We
we've
got
different
different
stacks
so
already
available
in
there.
B
And
basically,
what
you
saw
inside
of
the
define
ml
is
the
definition
of
the
components
plus
a
set
of
commands
that
you
can
run
inside
of
this
component.
This
component
is
a
container
that
is
getting
starting
on
the
cluster
remotely
and
if
you
are
using
the
vs
code,
openshift
connector,
for
example,
it
will
understand
that
that
component
and
each
time
you
will
do
a
build
of
your
your
source
code
from
the
s
card.
It
will
also
do
the
the
build
of
your
application
directly
inside
of
this
remote
environment.
C
So
things
are
actually
up
and
running.
It
actually
tells
you
what
url
that
I
can
use.
You
may
notice
on
the
url
that
I'm
using
actually
a
sandbox
environment,
so
so
that
means
you
can
easily
just
grab
a
sandbox
environment
yourself
and
then
try
it
out
yourself
at
home.
So
so
that's
that's
good.
Everything
is
up
and
running
now.
C
C
So
let's
say
my
application
needs.
Let's
talk
about
service
mining.
Let's
say
my
application
needs
to
use
some
back-end
services
in
order
to
function
properly.
Now,
if
I
want
to
link
a
surface
to
this
application
in
this
cluster,
I've
got
a
I've
installed
a
surface
binding
operator
in
there.
I
can
check
out
the
list
of
available
surfaces
in
the
cluster
using
an
audio
command.
Let
me
do
a
audio
catalog,
yes,
so
this
will
list
all
the
services
that's
currently
running
on
my
cluster,
so
you
may
notice.
C
There's
a
service
binding
operator
service.
I
have
it
running
in
there,
given
that
I
have
that
I've
got
an
example
surface
running.
I
can
link
the
example
service
to
my
application
using
audio
surface
create
command.
So
let's
try
to
do
that
to
create
service.
Basically,
you
want
to
saying
that
I
want
to
create
a
service.
I
need
to
tell
it
what
the
operator
and.
B
C
Is
that
I
want
to
create
with
so
basically
the
information
that
I
can
see
from
the
audio
service
listing
and
that's
as
simple
as
that,
I'm
actually
linking
that
to
my
application.
So
if
I
take
a
look
at,
let's
see,
what's
actually
in
the
developer
demo,
so
you
may
notice
there's
actually
a
inline
japanese
segment
has
been
added
to
that
file
for
you
as
part
of
the
command.
C
So
this
one
has
got
that
it
gives
you
it
a
name
with
the
examples
of
its
binding
in
there
and
then
the
content
of
it
is
basically
the
service
that
I
want
for
this
respect
of
the
service
that
I
want
for
creating
it
based
on
the
what's
actually
on
the
on
on
the
example
so,
but
just
do
that,
let's
just
do
an
audio
push
again,
it's
the
exact
same
command
that
I
was
using
for
pushing
the
application
before
and
let's
just
do
a
bill.
C
C
Is
that
going
okay
for
me?
So,
what's
what
it
does
is
it
takes
still
takes
the
instructions
from
my
from
my
dev
file
and
then
running
through
it.
Now
it's
creating
and
create
a
corresponding
surface
as
I
associate
with
it.
So
let
me
do
our
audio
service
list.
C
C
If
we
take
a
little
take
a
look
at
the
cool
results
we
can
see
from
the
spec
field,
you
can
set
that
the
exact
same
information
that
has
been
defined
in
the
that
file
demo.
So
basically
we
take
that
instructions
into
that
file
and
then
translate
it
and
then
link
it
link
the
application
to
surface,
and
you
may
notice
that
on
the
labels
it
actually
tells
you
that
I'm
actually
linking
to
my
applications
with
the
that
I
I'm
having
it
running
on
audio
as
well.
C
So
so
far
we
have
seen
the
usage
of
a
staff
from
a
community
repro.
Let's
say
I'm
not
a
more
advanced
users
and
the
stack
in
the
committee
report
are
not
enough
for
my
usage.
I
can
create
a
custom,
some
registry
and
use
my
own
stack
to
tailor
for
my
development
environment
team.
So,
let's
see
how
I
can
make
use
of
our
customer
registry.
C
So
in
in
this
cluster,
I've
got
a
custom
dev
file
registry
installed.
Let
me
just
do
a
guest
service
to
show
you
the
service
that
I
have.
You
may
notice
this
actual
one
that
I
have.
This
is
a
def
hour
history
that
I
have
installed
on
the
customer
registry
on
the
on
the
cluster
before.
C
Okay,
so
this
will
make
audio
recognized
by
customer
registry.
Now,
if
I
do
a
audio
catalyst.
C
Components
again,
you
may
notice
something
different,
so
this
is
the
new
one
that
I
have
added
to
the
registry.
So
uirat
one
is
the
registry
that
I
just
got
added.
You
can
see
now
that,
when
by
just
doing
that
simple
command,
it's
now
recognizing,
what's
in
the
custom
registry
that
I
have,
I
just
have
one
single
stack
in
there,
so
I
can
actually
make
use
of
it
in
the
same
way
as
what
I
used
before.
So,
let's,
let's
try
that
and
do
our
audio
create.
C
C
So
the
application
has
been
created,
it's
pretty
much
the
same
application
as
one
we
have
before,
but
what
you
notice
that
that
file
is
actually
different
on
this
one,
because
it's
actually
not
coming
from
the
public
community
registry
is
actually
making
use
of
what
we
call
the
parent
support
of
that
it
interprets
the
behavior
from
another
dev
file.
The
user
can
use
this
parent
support
in
that
file
to
tailor
the
existing
parent
dev
files
to
feed
the
need
of
the
application.
C
I
can
do
customization
on
that,
basically
overriding
the
fields
from
the
parent,
so
in
this
particular
case
I'm
actually
calling
a
parent
from
from
our
public
registry
for
it,
but
just
to
show
you.
This
is
how
this
another
thing
that
you
can
actually
do
for
that
file.
You
can
actually,
you
know,
heard
behavior
from
other
from
other
existing
files
as
well,
so
so
just
that
I
can
just
do
from
now
on.
C
I
can
just
do
the
same
audio
push
as
before
and
it
will
just
run
the
application
and
I
can
just
run
the
and-
and
we
just
deploy
as
as
before,
so
you
can
now
see
that,
even
though
I'm
using
a
custom
registry,
the
workflow
from
from
that
is,
is
exactly
the
same
as
what
I
will
be
using
as
a
public
community
registry
and
the
same
for
our
product
register
as
well.
So
I
think
yeah.
So
that's
that's!
C
This
concludes
the
first
part
of
the
demo
for
using
that
file
with
the
audio
ci.
Let's
switch
gear
and
take
a
look
at
the
dev
file
usage
in
idea
environment.
So
can
I.
A
Ask
a
question
real,
quick
sure
about
the
the
parent
dev
file
like
what's
the
hierarchy
there.
If
I,
if
I
I
inherit
a
parent,
you
know
dev
file
from
and
how
do
I
change
a
setting,
or
you
know
say
nah
instead
of
you
know
this,
you
know
y
release
I
want
a
later.
One
kind
of
thing
is:
is
that
possible
with
the
inheritance
process?
Yes,.
C
All
the
fields
in
there
the
difference
between
a
parent
that
file
ones
like
this
after
you
refer
to
your
parent.
If
you
put
the
same
sessions
in
here
under
the
parent
session,
then
it
will
just
do
an
override
for
it.
Now,
if
you
just
add
these
elements
outside
of
the
parent
one,
then
it
will
do
an
addition.
So
that
means
I
can
actually
define
new
containers
on
top
of
an
existing
parent,
that
file
and.
B
C
B
Cool
yeah.
Basically,
the
idea
is
that
we
have
the
file
for
stacks,
which
can
then
be
extend
for
different
teams
with
a
set
of
different
tools.
So
this
way
I
can
inherit
from
the
parent
definition
use
that
for
my
own
stack
definition
and
then
I
can
even
refine
that
for
the
for
a
dedicated
project,
for
example,
so
I
can
really
tailor
the
file
to
the
needs
that
that
I
have.
B
But
the
idea
is
really
to
let
some
people
looking
at
the
file
making
sure
that
they
are
looking
great.
They
are
well
shaped
and
they
are
defining
the
developer
environment.
That
is
needed
exactly
the
way
it
is
needed
and
then
the
developers
they
don't
have
to
worry
about
that
they
don't
have
to
touch
with
the
yammer.
They
don't
have
to
interact
that
much
about
that.
With
with
this
file,
they
just
have
to
leverage
it
within
their
tools,
as.
B
But
it
could
be
with
with
vs
code.
It
could
be
with
what
we
are
calling
devworkspace,
which
elsan
is
now
going
to.
C
Yeah
and
then
one
more
point
I
want
to
point
out,
is
you
may
notice
that
that
file
yemo
is
actually
putting
right
into
your
project
source?
That
means
you
can
actually
check
that
into
the
team
repository
just
like
any
other
thing,
so
I
can
develop
it
with
that
file
specified
and
customize
it
already,
and
I
can
change
the
team.
Repository
and
stephon
can
just
check
it
out
and
then
just
run
it
using
a
different
tool
and
it
will
still
behave
in
the
same
way.
C
So
that's
the
future
of
file
in
there.
That's
awesome.
So,
let's
go
to
the
second
demo.
I've
got
a
video
on
that.
I'm
going
to
show
how
that
file
helped
to
set
up
an
ide
environment
using
that
workspace,
ecoshade
has
built
with
that
file.
A
concept
called
that
workspace,
which
allows
to
define,
configure
and
start
an
ide
for
your
project.
C
C
C
C
C
C
C
So,
let's
take
a
look
at
the
parts
there
are
four
containers
created
for
you
just
for
information,
two
of
them
one
is
what
is
the
node.js
application
defined
in
that
file?
The
other
is
the
mongodb
defined
in
the
dev
file
and
also
and
the
rest
of
the
other
two
are
the
theoretical
and
some
utility
container.
C
C
So
now
she
will.
She
will
actually
based
on
my
dev
file
information
and
then
run
the
application.
So,
let's
see
I've
got
the
application
up
and
running.
Let's
try
it
out
I'll.
Add
a
entry
of
my
employee
in
there
to
save
everything
goes
well
and
let's
say
if
I
want
to
remove
this
application
in
this
this
user
employee.
C
C
C
C
C
C
B
So
so
I
think,
for
for
the
demo,
the
thing
that
is
pretty
cool
is
that
you
have
the
file.
You
can
use
the
chair
and
devour
space
to
get
a
complete
developer
environment
that
is
running
on
kubernetes,
to
build
a
code,
your
application
for
kubernetes,
as
well
so
you're,
you're,
directly
coding
from
from
kubernetes,
and
you
have
been
leveraging
all
the
different
components
that
are
defined
into
the
the
file
as
well.
So
that's
pretty
cool.
B
Actually,
you
can
spin
up
a
developer
environment
just
in
a
in
a
matter
of
few
few
clicks
and
you
can
get
going
and
start
coding
on
the
application.
So
imagine
that
you
are
working
on
multiple
micro
services
and
you
want
to
switch
from
editing
one
of
the
micro
services
to
editing
another
one,
that's
very
handy
because
you
just
have
to
to
open
it
into
a
different
browser
tab
and
you
have
an
environment
that
is
already
for
you.
So
that's.
B
C
Yeah
and
add
on
to
that,
we
also
believe
in
developers
have
different
favors
of
the
choice
of
the
tools
as
well.
So
that's
why
we
try
to
develop
this,
that
file
format
so
that
you
can
actually
use
the
tools
that
you
want
for
it.
C
So
on
an
audio
and
that
workspace
with
default
support,
we've
also
added
like
a
depth
preview
on
the
default
supporting
the
openshift
developer
console
the
support
allows
you
to
basically
import
a
git
repository
that
contains
the
dev
file
and
then
the
dev
tool
will
run
edition
for
you,
based
on
the
information
to
use
that
you
can
create
a
project
to
contain
the
application,
as
usual.
C
Then
you
can
use
the
import
from
that
file
tile
and
add
an
input
on
the
repository
information
or
use
the
sample
url
that
we're
providing
as
part
of
the
ui
and
once
you
do,
that,
that's
it
that
that's
fairly
simple
and
dev
console
will
just
take
data
file
trying
to
build
build.
It
build
the
application
for
you
and
you
can
just
launch
the
launcher
url,
just
like
any
other
applications
in
in
the
dev
console.
C
B
C
C
So
that's
that's!
A
quick
intro
on
the
dev
console
integration
on
it.
C
So
in
this
sessions
we
have
talked
about
how
that
file
works
and
how
it
can
help
you
to
develop
your
application,
how
you
can
moving
it
across
different
and
different.
A
variety
of
environment,
for
example,
a
cli
to
an
ide
to
a
dev
console
yeah.
So
we
also
also
demoed
how
depth
files
can
be.
C
B
C
File,
api
repro,
that's
our
main
repo.
Is
there
we're
currently
working
with
another
major
car
renter
for
trying
to
propose
that
files?
The
default
specification
together
with
that
workspace
as
a
cncf
project
as
well?
C
So
I
think
that's
it!
That's
all
we
want
to
show
today.
Let
us
know
if
there's
any
questions
on
that
file.
B
Sorry,
yes,
the
push
on
on
cncf
is
something
that
we
really
believe
is
is
interesting,
because
we
see
that
there's
multiple
tools
that
are
having
some
kind
of
a
similar
approach,
defining
developer
environment
in
a
codified
way.
You
have
things
from
dev
containers,
you
have
it
pod.tmls,
you
have
other
other
environments.tml
from
binder,
for
example,
and
things
like
that,
so
there's
a
lot
of
kubernetes
tools
in
the
space
that
are
looking
at
this
this
this
problem.
B
But
we
believe
that
there
is
a
need
to
work
all
together
on
a
vendor,
neutral
aspects
and
a
vendor
control
specification
format
which
can
then
be
used
by
by
others.
So
it's
going
to
be
interesting
and
it's
going
to
be
also
probably
valuable
to
the
community
overall.
A
You
know
because
I
remember
back
in
the
day
passing
around
multi-gigabit
vagrant
images.
You
know
right
yeah.
I
would
much
rather
pass
around
a
file
or
you
know
a
folder
directory.
You
know,
structure
of
files
if
need
be,
to
get
up
and
running
as
opposed
to
you
know,
oh
yeah,
by
the
way
you
have
to
do
all
your
development
in
a
vagrant
box
and
yeah.
A
B
C
B
Go
back
in
time
and
fix
an
issue
on
the
mountain
on
the
ocean
and
you
need
to
to
get
an
environment
set
up
to
do
that.
How
do
you
do
this
today?
Right?
That's
a
also
pain
point.
So
if
we
have
this
definition
of
the
developer
environment,
that
is
getting
version
along
with
the
source
code,
it
can
go
a
long
way.
A
A
B
So
we
are,
we
are
currently
working
on
a
viewer
for
the
defile
registry,
so
this
will
allow
to
to
browse
and
see
all
the
stacks
that
are
available
on
the
community
registry.
So
if
anybody
is
interested
to
provide
their
stacks
for
a
particular
framework,
they
could
contribute
that
directly
to
the
community
registry.
B
B
A
C
Yeah
and
then
the
main
idea
is
that
it's
especially
useful
in
the
case
where
you've
got
an
existing
application
that
I
now
want
to
take
advantage
of
to
that
file.
I
want
to
run
in
a
containerized
environment,
so
if
you
we
can
actually
do
that,
detection
tells
you.
What
is
the
best
matching
stack
that
you
can
use
and
you
can
just
you
can
just
throw
your
that
file
and
then
it
will
be
part
of
your
application.
A
That's
awesome
that
I
mean
it's
cool,
that's
cool
stuff,
right
like
point
it
at
github
repo.
Tell
me
what
I
need
and
then
go
from
there
kind
of
thing:
that's
truly
powerful.
So
thank
you
for
sharing
that.
I
appreciate
it.
So
no
questions
in
chat
and
if,
if
y'all
don't
have
anything
else,
I
don't
have
anything
else
either
we
can
wrap.
You
know
I
can
give
you
seven
minutes
of
your
time
back.
If
you
want
and
appreciate
you
coming
on
showing
this
off
for
us
thanks
for
having
us
that's.
What's.
A
No
problem
at
all-
and
you
know
hey,
I
look
forward
to
hearing
from
you
in
the
future
too.
Coming
up
next
on
the
channel
is
openshift
commons
briefing
my
calendar
is
being
very
slow
there.
We
go
we're
going
to
be
talking
about
serverless
and
serverless
functions
with
9sang,
so
please
tune
in
for
that.