►
Description
Eclipse Che is a next generation cloud IDE and developer workspace server that allows anyone to contribute to a project without having to install software. Che uses a server to start and snapshot containerized developer workspaces attached to a cloud IDE. This makes developer workspaces portable, recipe-based, and scalable. We’ll demonstrate how Che can be used by a development team with a multi-container application to speed project bootstrapping.
Presenter: Brad Micklea, Red Hat (via Codenvy) is an Eclipse Che committer and he ran marketing, services and operations for Codenvy before it was acquired in May 2017 by Red Hat.
A
If
those
of
you
who
don't
know
code
entity
was
recently
acquired
by
Red
Hat,
because
we
just
thought
it
was
such
awesome
stuff
and
we're
really
pleased
to
have
them
as
part
of
the
Red
Hat
family
now,
but
I
really
going
to
let
Brad
introduce
himself
and
his
topic.
Containerized
workspaces
for
nick
cloud
native
development
and
the
format
for
today's
session
is
he's
going
to
give
a
presentation
and
some
demos
for
about
a
half
an
hour
or
so
and
then
we'll
have
Q&A
live
Q&A
afterwards.
A
B
Thanks
very
much
Dianne
thanks
for
for
having
me
it's
interesting
actually,
because
Diana
and
I
met
at
that
summit
before
Cody
was
acquired
and
talked
about
doing
this,
so
it's
a
kind
of
fun
to
have
set
it
up
been
acquired
and
now
doing
it
from
kind
of
within
Red
Hat.
So
I'm
gonna
talk
to
you,
though,
about
today,
is
eclipse
J,
which
is
a
course
an
upstream
open
source
project
and
specifically
about
containerized
workspaces
for
cloud
native
development.
This
is
an
area
that
I
write
about
periodically
on
on
medium
and
other
places.
B
So
things
are
much
better
with
containers
today
than
they
were
back
then,
but
we'll
talk
a
little
bit
about
kind
of
the
state
of
things
today,
specifically
one
of
the
things
I
find
interesting,
you
didn't
when
I
look
kind
of
at
a
very,
very
high
level
at
the
market
knowledge.
This
is
a
big
simplification
is
that
you
have
over
80%
of
enterprise
companies
at
this
point,
reporting
that
they
are
using
continuous
integration
tools
and
doing
consent.
Continuous
integrations.
B
That's
a
huge
percentage
really
like
things
that
very
very
few
now
are
not
using
it
in
some
capacity.
But
when
you
look
at
the
development
side,
that
part
is
not
continuous.
That
part
is
not
yet
been
automated,
containerized
and
kind
of
made
more
efficient,
in
fact,
really
that
the
technology
that
we
use
as
developers
to
build
all
these.
You
know
machine
learning,
cloud
native,
continuous
integration,
all
these
wonderful
tools
to
help
everybody
else,
the
ones
that
we
use
ourselves
are
still
locked
very
much
into
our
desktops.
B
You
know
this
piece
of
functional
that
one.
What,
if
I,
have
the
wrong
package
on
my
machine,
all
those
things
which
often
are
subtle
or
very
obvious
inhibitors
to
people
absorbing
and
playing
with
open-source
technology?
We
just
said
you
know
it
feels
like
we're
far
enough
along
in
the
technical
cycle
that
this
shouldn't
need
to
be
the
case
and
as
we
began
to
look
at
the
problem,
we
kind
of
started
with
the
obvious
question.
B
Well,
what's
needed
in
order
to
make
a
contribution
to
a
project,
an
open-source
project
or
whatever
you
need
an
IDE,
obviously
or
some
kind
of
code
editor.
You
need
a
set
of
project
files,
which
is
your
source
code,
but
you
also
need
a
runtime,
because
no
one
writes
code
that
is
never
gonna
get
run
now.
A
desktop
IDE
has
a
concept
of
a
workspace,
and
when
you
speak
to
somebody
who
uses
a
desktop
ID-
and
you
say
the
word
workspace,
what
they
think
of
is
the
project
files
and
the
configuration
around
that.
B
But
what
it
explicitly
excludes
is
the
configuration
of
the
ID
itself,
the
installation
of
the
ID
itself
and
the
installation
configuration
of
the
runtime.
That's
a
lot
of
things
really
that
it
excludes
the
other
thing
we
very
quickly
realized
and
I.
Think
now,
especially
as
as
cloud
has
become
so
pervasive
in
every
part
of
what
we
do
is
that
the
local
host
runtimes,
which
have
kind
of
stood
as
well
as
developers
for
so
long.
Our
laptops
and
our
desktops
really
are
constrained
they're
constrained
in
a
lot
of
ways.
B
You
could
technically
do
it,
but
it's
an
enormous
pain
and
controlling
the
laptop
itself
is
also
fairly
constrained.
There's
a
lot
of
variables
going
on
in
my
laptop
at
any
point.
In
fact,
at
the
beginning
of
this
presentation
you
saw
I
had
issues
with
blue
jeans,
because
I
had
slack
running.
These
are
two
unconnected
apps,
there's
a
reason
for
them
to
affect
each
other,
but
they
just
do,
and
so
that
becomes
a
sort,
sometimes
issues
and
problems.
B
As
we
put
this
together,
was
saying:
hey,
you
know,
the
continuous
integration
has
revolutionized
the
way
people
build
apps
the
way
they
move,
those
apps
forward
in
the
pipeline
towards
or
release.
We
should
be
able
to
do
the
same
thing
for
development.
It
should
go
beyond
just
I'm.
An
individual,
coder
I
should
acknowledge
my
place
within
a
larger
community,
a
larger
team
and
recognize
that
standardization
of
runtimes
of
tools
doesn't
necessarily
mean
a
reduction
in
choice,
but
it
can
mean
a
reduction
in
issues
and
problems
and
speed
bumps
all
right.
B
So
enough
talking,
let's
see
what
what
she
looks
like
now.
One
of
the
easiest
ways
to
get
into
eclipse
Shea
is
obviously
from
the
site.
You
can
kind
of
go
in
and
do
either
a
sass
based,
install
blush
and
say
install
you
can
open
an
account
in
the
on
our
sauce
or
you
can
do
a
local
install.
Now
both
get
you
the
exact
same
functionality.
The
sass
is
my
preferred
way.
Just
because
I
find
it
easiest.
Frankly,
I
don't
need
to
have
docker
installed.
B
They
don't
need
to
do
anything
with
my
own
machine
and
I
kind
of
escape
those
localhost.
You
know
runtime
limitations.
Now,
if
I
do
that,
I
can
go
and
just
create
a
workspace,
of
course,
but
the
other
kind
of
cool
thing
about
packaging.
Every
piece
of
a
project
together
into
a
single
configuration
like
J
does
is
that
you
can
now
start
to
create
launch
points
for
projects.
B
So
if
I'm
particularly
interested-
let's
say
in
vertex
as
a
project,
maybe
I
played
with
it
instead
of
having
to
you,
know,
go
and
configure
everything
manually,
I
could
click
this
button
or
in
fact,
I
can
go
directly
to
the
repo
and,
if
I
come
down,
you'll
see
there's
a
developer
workspace
button
if
I
just
click.
This
gonna
go
and
pop
me
right
into
eclipse
a
running
in
the
codenvy
cloud,
and
it's
gonna
configure
me
a
workspace
perfect
for
vertex.
You
can
see
it's
grabbing
the
docker
container.
B
Now
it's
an
instantiate
that
docker
container
it's
going
to
then
inject
agents.
That
is
what's
happening
now,
so
we
keep
the
the
recipe
for
the
docker
container
standard
so
that
it
could
be
a
recipe
that
is
pulled,
let's
say
from
your
production
environment
and
then,
after
the
fact,
we
inject
agents
which
developers
need
things
like
you
know:
terminal
access,
SSH,
perhaps
a
debugger
language
services
to
allow
you
to
do
autocomplete
or
error
checking
for
the
particular
language.
Once
the
containerized
workspace
has
started
kind
of
under
the
hood
so
to
speak,
then
we
start
the
IDE.
B
This
is
a
lightweight
browser-based
ide.
As
you
can
see,
it
takes
about
a
hundred
Meg's
per
tab
in
my
browser,
so
not
a
great
deal,
but
it
is
an
actual
ID.
It
does
have
you
know
debugging.
It
has
autocomplete.
It
has
a
lot
of
the
functions
that
you'd
expect
out
of
an
IDE
the
nice
thing
about.
It,
though,
is
I,
haven't
needed
to
install
anything.
B
I
haven't
needed
to
configure
anything,
although
I'm
running
this
right
now
on
a
laptop
I
could
and
have
run
Eclipse
J
and
codenvy
like
this
on
a
Chromebook
we
actually
have
or
I
have
customers
of
codenvy,
where
the
dev
leads
sometimes
use
their
iPads
to
go
into
code.
Envy,
look
at
the
at
the
at
the
at
the
code
and
and
do
checks
for
you
know,
code,
reviews
or
whatever
have
you,
so
they
don't
necessarily
need
to
be
at
their
computer.
B
Now,
I
mentioned
autocomplete.
If
I
hit
control
space,
I
get
standard
autocomplete
and
if
I
do
that
again,
it's
basically
instantaneous.
You
can
see
now
the
reason
why
and
a
lot
of
people
that
kind
of
surprises
them.
They
expect
a
cloud
IDE
to
be
laggy,
because,
logically,
what
you
imagine
is
happening
is
that
my
browser
is
sending
a
packet
of
information
back
to
some
service
which
is
going
to
analyze.
It
kind
of
in
a
centralized
way,
interact
with
the
code
in
a
separate
container
and
then
send
the
results
back
to
my
browser.
B
But
that's
not
what's
happening
here.
What
we've
done
actually
is
inject
the
code
clone
dot
into
our
my
personal
container
inside
that
container
we've
injected
the
language
server
in
this
case
for
Java,
so
that
language
server
is
operating
directly
with
in
kind
of
a
localhost
relationship
to
the
code
and
the
only
thing
that
gets
sent
between
the
browser
IDE
and
that
container
are
the
set
of
events
and
very,
very
small,
lightweight
kind
of
messages,
but
not
not
full
content.
That
content
is
then
stored,
partly
on
the
on
the
browser,
so
that
can
be
optimized.
B
As
a
result,
you
get
very
very
fast
response
time,
even
over
quite
a
large
distance.
Now
I
can
do
other
things
like
let's
take
name.
This
is
such
a
small
little
app
I.
Don't
know
that
this
is
gonna,
be
the
best
example,
but
let's
see
if
I
can
get
them
on
the
same,
all
right
so
I'm,
gonna
take
name
and
now,
let's
say
I
want
to
do
some
refactoring
and
I
want
to
read
that
to
my
name,
and
you
can
see
done
now.
B
This
is
too
simple
an
app,
but
if
this
was
a
multi
project,
multi
class
packaged
app,
the
refactoring
also
works
kind
of
at
those
levels.
So
I
can
refactor
the
class
I
can
refactor
the
project
the
packages
it's
going
to
move
everything
around.
For
me,
it's
got
error
checking.
So
if
I
do
something
silly
and
just
add
in
a
package
that
I'm
not
actually
using
it's
gonna
go
and
say:
hey
you're,
not
actually
using
this,
you
don't
need
it
so
I
can
go
and
kill
it
clean
things
up
for
myself
and
you
saw
there
I'd.
B
Actually,
let
me
just
do
that
again
to
call
attention
to
it.
A
little
bit
better
that
the
autocomplete
is,
of
course,
location
specific
in
this
case,
because
I'm
up
in
the
import
section,
it's
going
to
show
me
autocomplete
of
a
bunch
of
packages.
It's
not
going
to
go
and
show
me
individual
classes
and,
of
course,
I
don't
see
packages
when
I'm
down
I'm
down
inside
the
class
I
can
of
course
navigate
around
the
file.
This
is
a
very,
very
small
and
simple
file.
So
that's
not
going
to
be
super.
Exciting
I
can
enter
open
declarations.
B
B
So
all
those
kind
of
editor
interaction
things
are
there
that
you
would
expect
now.
You'll
also
notice
that
at
the
bottom
here,
I
have
a
terminal
now,
in
this
particular
case,
I'm
only
running
a
single
container,
the
color
by
the
way
of
this
container
name
in
this
case,
WS
machine
indicates
its
running
status.
So,
in
this
case
it's
green,
always
good
I've
got
my
terminal
here
and
I
have
root
capabilities.
I
can
you
know,
do
whatever
I
want?
I
could
run
the
Tompa
five
I
want
and
just
check
out.
A
B
And
you
can
see
that
I've
got
the
same
structure.
Actually
I
guess
I
should
open
it
up
here.
That
I
would
hello,
so
these
are
both
using
the
exact
same
source
code
pulling
from
the
same
location.
The
changes
that
I
make
down
here
will
be
reflected
above
so
if
I
go
back
down
here
and
let's
go
into
vertical
and
there's
my
new
file,
dot,
txt
and
I,
of
course,
can
edit
it
and
you
can
see
the
Edit.
Is
there
so
lots
of
interaction?
B
I
can
use
this
just
as
I
would
any
other
IDE
and
of
course,
I
can
use.
I
should
be
clear,
any
other
IDE
I
don't
have
to
use
this
browser-based
ID.
So
if
I'm
particularly
married,
you
know
to
IntelliJ
or
the
Eclipse
desktop
IDE
or
sublime,
or
you
know
whatever
I
want.
I
can
actually
use
a
mountain
sync
between
my
local
machine
and
my
local
file
system.
Where
that
you
know
desktop,
IDE
will
interact
over
to
the
container
where
my
app
is
located.
B
This
gives
me
the
kind
of
familiarity
of
my
desktop
ID
for
the
points
where
I'm
doing
actual
editing
but
allows
me
to
build,
run.
Execute
tests
inside
the
containerized
runtime,
which
is
provided
by
a
close
check
so
for
some
people,
that's
kind
of
the
best
of
best
of
both
worlds,
obviously
have
git
and
subversion.
Menus
I
can
interact
with
with
get
over
here
check
out
all
the
branches
origins,
local
branches,
everything
else
or
get
is
typically
installed,
also
in
the
command
line,
and
so
I
can
do
it
directly
from
the
camp
command
line.
B
Whatever
my
preferences
now,
let's
actually
shutdown
this
and
let's
show
a
slightly
meteor
example.
So
let's
go
back
into
the
dashboard,
and
although
this
is,
as
I
said,
kind
of
all
hosted
on
codenvy,
the
which
everything
I'm
showing
you
here
is
Eclipse
J.
It's
just
that
it's
being
run
inside
the
code
into
the
cloud,
so
it's
going
to
create
a
workspace
and
let's
do
something
a
little
bit
more
in-depth.
So
the
concept
in
J
of
a
stack
is
quite
important.
B
A
stack
is
basically
a
set
of
runtime
infrastructure
and
dependencies,
which
I
can
inject
my
code
into
and
get
my
running
application.
Now
we
package
a
number
of
stacks
in
what
we
call
of
our
stack
library
and
you
can
see
for
a
large
number
of
different
languages.
You've
got
all
these
different
pre-built
stacks
kind
of
optimized.
B
For
that
language,
you
can
also
import
a
stack
if
you
have
a
recipe
elsewhere,
that's
in
a
composer,
docx
file
or
I
can
just
start
typing
a
docker
file
here,
Eclipse
bun
too,
and
that's
going
to
get
the
on
Ubuntu
container
from
the
Eclipse
Foundation.
But
let's
go
back
to
the
ready
to
go
stacks,
because
what
I
actually
want
to
do
is
do
a
multi
container
application.
B
Increasingly
as
developers,
we
are
working
on
more
complex
applications
and
microservices
and
we
want
to
be
able
to
kind
of
replicate
the
production
infrastructure
when
I'm
doing
my
death,
and
that
means
having
multiple
containers
with
their
own
network
in
place.
Let's
choose
the
job
in
my
sequel,
that's
going
to
give
me
a
Java
stack
and
a
my
sequel
database
separately.
I'm
gonna
come
down.
I
can
give
it
any
name.
I
want.
Let's
call
this
one
Commons,
it's
called.
Oh
s,
Commons
you
can
see.
B
Let's
go
ahead
and
create
it
now
the
process
is
going
to
be
the
same,
except
in
this
case.
You
can
see
that
we
were
kind
of
pre
pending
the
docker
instructions
here
with
which
of
the
the
containers
it's
operating
against.
So,
of
course,
we
start
the
database
first
and
see
we.
The
docker
container
was
instantiated.
Now
we're
executing
all
the
do
various
commands
in
order
to
start
up
my
sequel
load
in
the
data
set
and
etc.
Once
that's
complete
and
the
database
is
up
and
running,
then,
of
course
we'll
start
our
app
server
container.
B
B
Anyone
else
who
comes
in
to
chain
runs
the
exact
same
stack
with
the
exact
same
app,
we'll
get
an
identical,
containerized
environment,
but
it
won't
be
the
same
one.
We
will
each
get
our
own
copy
and
that's
because
it's
very
important
as
a
developer,
that
I
have
kind
of
my
own
sandbox
a
place
for
me
to
play.
I
might
want
to
invite
other
people
in
and
Kate
in
some
cases
to
help
me
to
work
on
the
same
app
with
me,
but
that
usually
isn't
the
default.
I
want
to
typically
have
my
own
space.
B
Now
you
can
see
my
OS
Commons
workspace
has
started.
The
IDE
has
been
spun
up
and
now
you
can
see
we
have
a
dev
machine
and
we
have
a
database
machine
now.
This
particular
terminal
that
I'm
seeing
here
is
in
the
dev
machine,
and
so,
if
I
look
there's
my
my
java
web
pet
clinic
app
and
I
can
go
into
the
source
code
here.
B
Of
course,
let's
split
this
and,
let's
add
a
terminal
by
clicking
on
that
little
button
for
the
database
and
of
course
my
database
looks
totally
different
now
one
of
the
things
and
remember
this
out
of
the
way
one
of
these
I
didn't
really
show
much
in
the
last
part
of
the
demo
and
actually
I'm
just
going
to
zoom
out
for
a
second
is
the
command
bar,
and
this
gets
pretty
interesting
in
this
type
of
configuration.
Well,
I
have
multiple
containers,
because
now
I
can
do
things
like
a
build
and
deploy
on
my
dev
machine.
B
Okay,
so
that's
going
to
start
and
that's
running
all
my
my
maven
commands
you
can
see
if
they're
going
by
rather
quickly
but
they're
there
and
if
I
go
into
run
and
into
my
command
palette.
I
can
see.
I
also
have
a
show
databases
and,
of
course,
when
I
run
to
show
databases,
I'm
gonna
run
it
against
the
dead
machine.
I
did
the
database
machine
not
the
dead
machine.
So
now
this
is
showing
me
the
databases
that
are
inside
my
my
sequel
and
there's
my
pet
clinic
now
I'm,
not
a
stupor
expert
in
databases.
B
So,
to
be
honest,
if
you'd
asked
me
how
to
show
a
database
in
my
sequel,
I'd
have
to
resort
to
Google.
The
nice
thing
is
that
when
I
create
these
workspaces
for
a
project,
I
can
embed
these
commands
into
it.
So
I
can
basically
pre
load
a
workspace
with
a
set
of
commands
that
have
value
for
people
contributing
to
this
particular
project
and
show
it.
Databases
may
be
one
of
them.
I
may
want
a
clear
data.
I'm
going
to
reset
data.
I
might
want
to
you,
know,
change
or
shutdown
and
restart
connections.
B
All
of
these
things
can
be
built
in
as
commands
and
each
individual
user
then
still,
of
course,
has
the
ability
to
override
commands,
change
them
or
delete
them.
So,
for
example,
if
I
take
the
build
you
can
see
in
this
case,
this
is
doing
an
MDM,
a
clean,
install
and
it's
doing
skip
tests.
Maybe
I
don't
want
to
skip
tests
so
I
can
either
create
a
new
build.
No
tests
or
I
can
just
delete
those,
because
it's
only
in
my
workspace
and
when
I
do
this
change
and
save
it.
B
B
The
preview
link
is
going
to
open
up
in
a
new
tab,
and
this
is
going
to
point
to
whatever
domain
in
my
Michael
che
has
installed
on
and
automatically
select
the
correct
port
and
that's
important,
because,
if
you've
been
using
containers,
much
you'll
know
that
when
you
open
port
8080
in
a
container,
it
doesn't
get
externalized
in
the
container
as
8080.
It's
actually
mapped
to
at
runtime
do
a
port
selected
at
random
from
the
ephemeral
range.
So
you
always
have
to
kind
of
figure
out
with
containers
where
your
critical
ports
have
been
mapped
to
eclipse.
B
J
takes
care
of
that.
For
you,
we
actually
have
a
number
of
macros
that
you
can
add
into
your
commands
to
determine
this
so
that
when
your
preview
URL
is
generated,
it
just
automatically
will
choose
the
correct
port
and
if
I
were
to
rerun
this
and
that
port
changes.
Of
course,
my
preview
URL
port
will
change
as
well.
It
makes
things
a
lot
easier,
my
pet
clinic
app.
So
of
course
it
it
works,
as
you
would
expect
I'm
going
back
and
hitting
the
database
for
all
these
things.
It's
just
the
standard
pet
clinic
ACK.
B
If
there's
not
much
too
exciting
about
it,
but
what's
I
think
important
here
again,
just
to
kind
of
re
emphasize
is
without
having
to
install
anything
without
having
to
configure
anything.
I
am
able
to
provide
for
users
of
my
projects,
the
project
developers
of
my
project,
contributors
to
my
project,
a
very
simple
single
link
which
brings
them
into
a
web
interface
in
which
they
can
edit
build
debug
run
change,
contribute
to
pull
request
to
any
project
that
they
want.
They
don't
need
to
know
a
great
deal
about
the
project.
B
I
can
preload
it
with
commands
so
that
everything
is
at
their
fingertips.
It
really
reduces
the
bar
for
community
contribution,
and
our
experience
has
been
that
it
makes
teams
whether
they're
teams
working
on
open
source
projects
or
on
closed
source
Enterprise
projects
far
more
efficient,
because
now
it's
much
easier
for
me
to
focus
in
on
what
I
need
to
do
as
a
developer
and
much
less
on
the
infrastructure.
I
need
to
do
it
last
thing.
I'll
talk
about
a
little
bit
is
sharing.
I
can,
of
course,
take
this
URL
up
here
at
the
top.
B
Select
my
workspace
and
go
to
share
and
now
I
can
actually
add
people
explicitly.
They
have
to
be
in
the
system
so
that
I
I
know
that
they're
kosher
I'm
pretty
sure
that
I've
got
yes,
my
personal
account
there
and
then
I
can
go
and
remove
them
change
them.
Anything
else
see
my
SSH
keys,
been
dropped
in
a
list
of
projects.
I
didn't
show
this
actually,
but
within
an
eclipse,
a
workspace,
you
can't
have
multiple
projects,
so
you're
not
limited
to
a
single
project
and
our
parlance.
B
C
B
Get
the
full
config
as
a
as
a
JSON
file
that
I
can
now
pass
to
somebody
else,
so
the
other
way
I
could
share.
This
is
simply
by
taking
this
contract
copying
it
and
sending
to
somebody
an
email
or
an
IM
and
they're
gonna
get
an
identical
configuration
to
what
I
have
in
every
way,
which
is
really
good
for
quickly.
Onboarding
people
are
getting
help
from
somebody
else
all
right.
B
All
right
so
as
Diane
mentioned,
I
looted
to
the
beginning
of
the
call
codenvy
engineers
originally
contributed,
Shea
to
the
Eclipse
Foundation
and
the
employees
of
codenvy
are
the
leads
and
many
of
the
committees
of
CheY.
Now,
of
course,
Jay.
Today,
as
oh,
you
know
over
a
hundred
contributors-
and
you
know
the
committers
are
much
broader
than
just
codenvy
employees,
but
there's
still
a
bulk
of
them
there
in
May
2017,
so
about
a
month
or
so
ago.
B
Red
had
actually
acquired
codenvy
and
we're
very
pleased
and
excited
to
say
that
the
big
part
of
the
driver
of
that
was
the
strength
of
the
Eclipse
J
project.
The
great
news
for
any
eclipse,
J
user-
is
that,
as
you
might
expect,
Red
Hat
will
be
open
sourcing
most
of
what
was
proprietary
codenvy
into
the
che
project
and
that's
important,
because
the
relationship
between
Shea
and
codenvy
was
a
kind
of
upstream
downstream
relationship
which
is
really
typical.
B
Codenvy
took
che
and
then
added
a
number
of
kind
of
what
we
call
enterprise
features
so
LDAP
integration
whole
auth
integrations
the
ability
to
do
multi-user,
multi-tenancy,
horizontal
scalability
across
clustered
nodes
to
allow
for
very,
very
large-scale
dev
teams
integrations
with
you
know,
third
party
tool
chains.
So
all
that
goodness
there
was
in
code
Envy
targeted
enterprises
bought
by
you
know.
Many
many
enterprises
is
now
going
to
be
pushed
into
the
upstream
che
project
for
everyone
to
consume
as
part
of
the
the
open
source
and
we're
super
excited
about
that.
B
It
was
something
that
has
code
nd.
We
didn't
have
the
resources
to
be
able
to
do,
but
it's
just
always
something
that
we
kind
of
wished.
We
could
do
so
big
thanks
to
Red
Hat
for
supporting
us
in
that,
and
that
makes
eclipse
chase
six,
which
is
in
development
now
I
think,
possibly
the
most
exciting
che
release
will
ever
have
made
you're
gonna
get
multi
user
and
authentication
from
codenvy
user
team
and
organization
management
from
code
Envy
permissions,
fine-grained
security,
SSL
from
code
Envy.
B
B
Red
Hat
engineers
for
the
last
nine
months
in
fact,
have
been
working
on
porting
eclipse
J,
which
was
kind
of
built
on
top
of
docker,
and
today
relies
very
heavily
on
docker
to
use
it
a
new
SPI
which
allows
for
kubernetes
and
openshift
as
alternative
what
we
call
machine
implementations.
In
other
words,
when
I
start
a
workspace
today
in
che,
it
always
starts
in
docker.
I,
don't
have
a
choice:
docker
is
the
orchestrator,
but
with
Chase
6
I
will
be
able
to
select
amongst
orchestrators.
B
Do
I
want
it
to
be
part
of
a
kubernetes,
install
an
open
shift
pod
or
a
docker,
so
I
have
a
lot
more
flexibility.
This
is
going
to
make
it
I
think
a
lot
more
appealing
to
a
lot
more.
His
Asians
out
there
we're
also
heavily
revamping
the
IDE
you're
gonna,
see
an
IDE
that
is
not
just
more
powerful
but
simpler
and
more
beautiful
and
that's
important
to
us.
B
We've
always
taken
the
approach
and
believed
very
strongly
that
the
IDE
within
che
we
didn't
want
it
to
be
just
like
the
Eclipse
desktop
ID
or
just
like
the
IntelliJ
IDE.
Although
those
are
impressive
tools
and
they're
very
powerful,
we
felt
that
you
know
they
had
tipped
over
into
a
level
of
complexity
that
was
unnecessary
for
many
people.
We've
always
wanted
the
Eclipse
che
IDE
to
remain
streamlined
and
as
simple
as
possible,
while
still
being
a
full-blown
IDE,
something
powerful
that
can
do
refactoring.
B
They
can
do
debugging,
they
can
do
those
tasks
which
you
expect
at
the
core
of
an
IDE,
so
I
think
we're
gonna
make
another
big
advancement
with
that
in
chase
X.
The
last
part
is
that
we're
going
to
be
expanding
the
language
support
via
new
language
server
protocol
integrations
now,
if
you're
not
familiar
with
the
language
server
protocol,
it's
pretty
exciting.
It's
a
a
protocol
standard
that
was
developed
by
Microsoft,
Red,
Hat
and
codenvy,
and
really
kind
of
flattens.
B
The
way
that
LSPs
have
been
done
in
the
past
so
rather
than
building
a
language
server
that
works
only
with
one
IDE.
It
detaches
those
two
concepts
and
you
get
a
language
server
which
can
be
plugged
into
es
code
or
Eclipse,
J
or
Eclipse,
desktop
IDE
and
on
and
on
there's.
More
and
more
IES
and
editors
are
supporting
the
LSP
a
protocol
going
forward.
B
But
it
also
means
that
folks,
like
Eclipse
J,
where
you
know
we
don't
necessarily
have
the
community
contributions
for
everybody,
just
go
and
start
building
a
brand
new
PHP
or
Python
or
C++
language
server
for
J.
We
can
now
absorb
those
from
wherever
they
pop
up
in
whatever
community.
So,
for
example,
early
in
the
che
5
released
rain,
we
got
a
rather
wonderful
little
surprise,
when's
end,
who
are
kind
of
the
preeminent
experts
in
PHP
contributed
a
fantastic
language,
server
to
different
debuggers
and
a
bunch
of
kind
of
Tory
and
dogs.
B
B
So
let's
talk
briefly
about
open
shift
IO.
This
is
kind
of
futures,
stuff
and
I
will
copy
out
this
by
saying
I'm
quite
new
to
the
open
shift.
Io
team,
but
I'll
tell
you
a
little
bit
about
what
I'm
excited
about.
So
this
is
not
necessarily
official
positioning
or
anything
like
that,
but
it's
just
it's.
How
I
think
of
why
open
shift
IO
is
exciting
to
me,
because
I
believe
that
every
development
project
needs
to
be
managed,
developed,
tested
and
deployed
with
professional
tools.
B
Giving
that
development
team
an
opportunity
to
kind
of
evaluate
that
choice.
Did
we
consciously
choose
to
use
something
unusual
and
different?
Maybe
it's
because
it
fits
our
needs
better.
Or
did
we
just
happen
upon
a
kind
of
narrow
little
path
in
the
woods,
not
realizing
that
there
was
a
superhighway
right
beside
us
and
we
want
to
jump
back
on
to
that
thing,
which
has
larger
community
support.
So
I'm
very,
very
excited
about
this.
B
As
you
can
see,
the
Eclipse
CheY
is
going
to
play
an
important
part
in
openshift
I/o,
as
kind
of
the
the
coding
engine
the
IDE
engine
within
this,
but
you
know
fabricate
Jenkins,
a
brand
new
issue
management,
all
this
intelligence
and
machine
learning,
plus,
of
course,
openshift
itself
are
just
kind
of
a
host
of
tools
that
surround
this.
I
can
make
it
even
more
exciting.
B
Alright,
last
couple
things
I
wanted
to
talk
about
was
bring
us
back
down
to
earth
a
little
bit
now.
What
I'm,
showing
you
here
is
the
impact
that
using
these
containerized
and
shareable
developer
workspaces
had
on
code
n,
B's
dev
team.
So
we
did
this
test
for
six
months
three
months
before
the
team
made
the
change
in
three
months
after-
and
this
was
done
this-
this
data
and
testing
came
from
a
couple
years
ago
at
this
point
now,
but
what
we
saw
was
pretty
impressive.
B
B
However,
thanks
to
optimizations
that
we
were
able
to
realize
through
using
these
containerized
workspaces,
the
number
of
commits
per
day
actually
increased,
because
developers
could
now
flip
from
branch
to
branch
project
project
rebut
a
repo
much
more
quickly
and
that
helped
to
significantly
reduce
the
amount
of
time
it
took
to
get
a
commit
out
into
production.
This
is,
of
course,
since
dropped
even
more
from
5.2
to
today,
so
I'll
wrap
up
there.
Thanks
very
much
folks
really
happy
to
answer
some.
Some
questions
now
well.
C
C
Thanks
Diane,
so
the
first
one
I
I,
see
that
it's
the
we
are
creating
containers
behind
the
scenes.
So
when
you
deploy
a
multi-tiered
or
when
you
are
trying
to
build
a
multi-tiered
application,
each
component
is
becoming
a
a
container.
It
is
running,
so
it
is
creating
a
continued
rise
to
workspace.
Now
is
that
container
I
think
a
part
of
the
patient
is
already
answered
by
Peter.
C
He
said
that
my
initial
question
was:
are
we
actually
passing
this
saving
this
container
itself
or
continually
made
itself
and
then
passing
that
container
image,
or
are
we
passing
the
code
from
that
container?
What
what
is
the
intent
there
and
I
think
Peter
said
that
it
is
still
get
based,
so
you
are
using
that
can
so.
Based
on
that
answer,
my
understanding
is
that
we
are
using
that
container
as
a
workspace.
That's
it.
Ultimately,
the
deliverable
from
this
IDE
is
still
the
code
to.
B
Do
is
still
get
pasted
and
the
code
still
resides
and
get
we
didn't
want
to
change
that
kit
does
its
job
very
very
well.
Now,
when
you
talk
about
passing
a
project
from
a
developer
to
a
developer,
though
there's
a
nuance
there.
If
all
I
want
to
do,
is
pass
the
code
itself,
then
of
course
get
does
that
perfectly
I
don't
need
anything
else?
B
What
eclipse
che
allows
me
to
do,
though,
is
pass
to
that
developer,
not
just
the
code,
but
also
the
runtime
needed
in
order
to
execute
that
code,
and
that
can
be
extremely
helpful
now
to
go
back
and
answer
your
first
question
fear.
The
image
itself
is
not
passed
from
developer
developer.
That
would
be
kind
of
unnecessarily
heavy.
B
What
I
pass
from
developer
developer
is
the
recipe
for
that
image
or
really
for
the
workspace,
and
that's
what
I'm
showing
now
so
this
JSON
file
you'll
see
includes
information
about
the,
for
example,
the
memory
for
the
database
and
for
the
dev
machine.
So
it
knows
how
much
to
provision
in
terms
of
size
for
those
machines
it
has
the
compose
file
built
in,
but
it
also
as
I
get
down
here
did
I
go
past.
It
notice
right
here.
B
B
This
file
and
I
know
that
they're
going
to
then
land
in
an
environment
that
is
set
up
the
way
my
environment
is
set
up,
they're
going
to
land
that
they're
gonna
pull
their
code
from
the
correct
branch
and
even
commit
ID
that
I
need
in
order
to
get
my
question
answered
from
them,
for
example,
okay.
So
that
gives
me
a
lot
of
a
lot
of
kind
of
precision
that
make
sense.
It.
C
Does
follow
up
on
the
same
exact
thing
that
you
said,
I
I
do
understand
the
reason
for
passing
this
JSON
instead
of
an
image
which
makes
sense
from
a
developer
to
a
developer,
but
if
I
could
get
an
image,
for
example
outside
this,
then
can
I
not
take
the
teammate
and
run
this
directly
on
my
box
and
use
that
image
directly
like
it
say
at
the
end
of
the
date.
Is
it
after
container
ID.
B
Only
oh
yeah,
sorry
I,
didn't
I
didn't
mean
to
imply
that
you
couldn't
do
that.
You
absolutely
can
it's
just
that
the
image
itself
is
quite
large,
and
so
generally
people
don't
want
to
move
it
around.
Remember
that
for
a
team-
and
here
I'm
going
to
be
talking
a
little
bit
more
about
Eclipse
chase
six
than
Eclipse
che
as
it
exists
today,
but
for
a
cliché,
six,
the
the
concept
would
be
that
you
would
run
a
centralized
kind
of
Eclipse
CheY
cloud.
B
Let's
call
it
for
your
team,
and
so
the
execution
of
those
containers
would
happen
on
a
on
a
centralized
set
of
resources.
As
a
results,
you
know,
I
don't
need
to
move
an
image
back
down
to
my
machine.
I
can
simply
kind
of
move
the
pointer
around
and
people
can
execute
those
images
on
that
central
resource.
Now
that
always
still
gives
me
the
option
to
pull
the
image
down
to
my
local
machine
running
on
my
local
machine.
If
I,
if
I
want
to
do
that
as
well.
C
Can
you
talk
a
little
bit
more
about
integration
between
a
desktop
IDE
like
eclipse
or
IntelliJ
or
Red
Hat's
jvd
is,
which
is
nothing
but
eclipse,
and
an
eclipse,
J
and
so
I
have
two
parts
of
the
question.
First
is
how
does
it
work?
Second,
is:
what
is
a
use
case
for
that
I
mean?
Is
there
a
reason
why
someone
would
want
to
do
it.
B
Yeah,
so
some
people
just
don't
want
to
use
the
cloud
based
IDE
like
I,
think
it's
really
kind
of
that
simple
I
like
it.
Obviously
a
lot
of
people
like
it,
but
not
everyone.
You
know,
naturally,
if
someone
has
been
coding
for
20
years
with
the
same
IDE
they've
developed
a
kind
of
muscle
memory
with
that
IDE
and
they
may
be
much
more
efficient
with
that
particular
desktop
ID,
then,
in
changing
to
another
one
others
in
some
cases
you
know
to
be
perfectly
honest,
and
this
should
be
no
surprise
to
anybody.
B
The
Eclipse
IDE
being
you
know,
5
years
old.
Let's
call
it
at
best
is
about
25
years
on,
you
know
garden,
let's
see,
maybe
20
15
20
years
less
feature.
You
know
growth
than
what
you
know.
If
something
like
the
Eclipse
desktop
ID,
he
does
so.
Naturally,
the
Eclipse
IDE
doesn't
do
everything
that
the
desktop
ID
does.
For
those
reasons
some
people
like
to
loot
use
their
local
IDE.
B
B
So
basically
you're
you,
you
create
a
an
ssh
FS
connection
between
a
local
folder
on
your
local
machine
and
the
filesystem
of
the
the
container
that
you're
targeting
within
codenvy
within
che
pardon
me
there's
an
initial
sink,
that's
done
by
unison
to
make
sure
that
those
two
file
locations,
look
correct
and
are
in
sync
and
then
as
you're
typing
and
changing
on
your
local
desktop
ide
and
that's
changing
files
on
your
local
folder.
It's
sending
those
changes
up
to
the
Eclipse
J
container.
B
B
The
use
case
for
that
is
for
situations
where
somebody
doesn't
want
to
give
up
their
desktop
IDE,
but
does
want
to
be
able
to
take
advantage
of
greater
resources
or
greater
flexibility
in
running
builds
and
executions
in
a
containerized
workspace,
maybe
on
a
shared
server
in
the
cloud
in
other
locations
where
they
could
end
up
with
more
horsepower
than
on
their
laptop.
For
example,.
B
Although
there's
a,
we
do
have
a
number
of
customers,
for
example,
who
just
very
very
large
and
demanding
apps,
and
some
things
were
data
science
and
things
like
that.
That
need
a
very
large
amount
of
horsepower
and
just
don't
run
happily
on
a
laptop,
and
so
in
those
cases
the
developer
may
want
to
use
a
desktop
IDE
to
do
the
editing.
But
the
actual
execution
of
the
jobs
is
much
better
suited
to
being
executed
on
a
much
larger
server
in
the
cloud.
B
B
Question
yes,
and
something
I
really
should
have
done.
Thank
you
for
that
question.
So
a
workspace
you
can
kind
of
think
of
as
the
as
the
thing
that
developer
interacts
with
and
touches.
Each
each
developer
gets
an
instance
of
a
workspace
and
that's
where
they
do
their
work,
a
stack.
You
can
think
of
a
bit
more
like
a
template
for
the
runtime
components
of
a
workspace.
Remember
that
a
workspace
includes
the
runtime
components,
plus
the
source
code
plus
the
IDE.
So
the
stack
really
is
is
targeting
that
runtime
aspect.
B
So
when
I
choose,
you
know
the
the
express
stack
it's
going
to
come
and
give
me
the
you
know
a
certain
Linux
version,
MongoDB,
Bao
or
node
express
NPM.
It's
going
to
put
all
that
set
of
infrastructure
and
packages
and
dependencies
I
would
need
to
do
Express
development
into
my
workspace.
It's
still
up
to
me
to
tell
it
where
do
you?
Where
do
you
get
my
actual
source
code
and
then
I
still
have,
of
course,
the
option
of
using
the
GI
de
or
a
desktop
IDE?
B
So
it's
a
stack,
and
so
what
people
tend
to
do
is
for
their
particular
project.
Unless
it's
fairly
vanilla,
they'll
often
create
a
custom
stack
one
that
is
really
appropriate
for
their
their
particular
project.
Just
the
tools
and
packages
that
they
need
for
that
project
to
work
and
I
can
share
those
stacks
in
the
same
ways
that
I
would
share
a
workspace.
So
I
could
share
that
with
the
rest
of
my
team
or
my
community.
Now,
a
factory
is
something
a
little
bit
different,
so
what
I
can
do
once
I
have?
B
So
if
I'm
working,
let's
say
in
an
enterprise-
and
everybody
knows
everybody-
it's
useful
to
use
this
top
one
because
it
indicates
who's
the
owner
that
created
it.
So
if
there's
a
problem
with
that,
they
can
come
and
yell
at
me.
If
I'm
doing
this,
maybe
for
a
public
project
on
github,
I'd
probably
use
the
second
one,
because
you
know
it
needs
to
be
maintained,
but
I'm
not
sure
I
want
to
expose
all
the
information
out
to
everybody
who
I
am
and
all
that
stuff
within
this
Factory
I
can
further
customize
things.
B
B
The
only
one
that
likes
to
show
databases,
I
can
just
delete
it
or
I
can
create
a
new
one
and
then
I
can
also
have
it
execute,
commands
upon
open
and
that
can
be
nice
again
to
just
simplify
things
for
people
so,
for
example,
within
codenvy,
when
we
had
a
feature
branch
that
people
are
working
on.
One
of
these
factors
we
created
for
the
feature
branch
and
there
would
be
two
of
them-
there'd-
be
a
developer
link
and
a
reviewer
link.
B
The
developer
link
would
just
open
up
as
you'd
expect
into
the
code,
so
they
don't
start
working,
but
the
reviewer
link
would
automatically
build
and
run
the
app
in
whatever
state
it
was
in
kind
of
the
state
of
head
of
master
so
that
a
reviewer
kind
of
didn't
need
to
interact
very
much
with
the
actual
IDE
they
just
clicked.
The
link
IDE
opened,
the
the
latest
code
commits
ran.
B
They
click
the
preview
button
banging
there
and
they
can
look
at
the
app,
but
it
still
allows
them
the
freedom
to
go
back
into
the
IDE
and
analyze
the
code
if
they
need
to
so
factors
are
really
good,
in
other
words,
for
sharing
a
particular
workspace
with
a
larger
group.
Now
the
last
thing
that
I'll
mention
it
isn't
in
the
in
the
menu,
because
it's
done
more
at
the
command-line
is
somebody
call
shader.
Now
Chater
is
kind
of
cool
with
trader.
B
You
actually
drop
a
set
of
config
files
into
the
root
of
your
repo,
and
then
somebody
can
actually
run
shader
up
on
their
local
machine
and
it
will
actually
not
just
clone
the
repo
but
actually
pull
down
all
the
containers
needed
in
order
to
run
it
on
their
local
machine.
So
if
you
do
prefer
running
Eclipse
J
on
a
local
machine,
I'd
have
been
your
own
little
sandbox.
Then
a
shader
is
kind
of
very
similar
to
the
factory
concept,
but
brings
that
to
your
local
machine.
A
Well,
well,
that
brings
us
almost
to
the
end
of
our
hour
here
and
I.
Think
there's
been
a
couple
of
other
comments
and
questions
about
openshift,
IO
and
I.
Just
wanted
to
reiterate
what
Peter
said
in
the
chat
was
that
open
ship
do
is
in
heavy
heavy
development
in
the
Alpha
and
we've
all
been
a
little
overwhelmed
by
the
interest.
B
Absolutely
so
the
eclipse
shape
project
is
hosted
on
github.
You
can
go
to
eclipse
/j
everyone
hangs
out
here.
It's
a
this
is
really
the
locus
of
everything
we
do
with
Jay.
So
if
you
have
questions
you
can
file
them
as
github
issues
and
and
people
will
jump
all
over
those.
You
can
check
out
pull
requests
of
course,
but
in
the
wiki
also
we
have
things
like
the
road
map.
We
have
weekly
milestone,
meetings,
planning
meetings
which
are
in
blue
jeans,
so
you
can
just
click
the
link
and
join
it
every
Tuesday
at
7
a.m.
A
Well,
thank
you
and
I
think
when
we
have
the
next
release
out
that
maybe
we'll
get
another
go-around
and
as
it
comes
up
and
surfaces
more
in
openshift,
IO,
I'm
sure
I'll
have
the
open
ship
that
IO
guys
come
and
give
a
more
full-blown
talk
on
on
that
home
workflow
as
well.
So
thank
you
very
much
Brad
for
taking
the
time
and
for
everybody
who's
joined
us
today.
Again.
I'll
reiterate
tomorrow,
is
the
kubernetes
1.7
release
update
from
clayton
Coleman
same
time,
check
the
calendar
at
comments
at
OpenShift,
org,
slash
events
for
other
upcoming
things.
A
So
thanks
again
and
this
recording
will
be
posted,
probably
in
a
day
or
so
on
the
YouTube
channel
and
then
in
a
blog
post,
with
reference
links
back
to
some
of
the
eclipse
project
staff
on
blog
that'll
Bishop.
So
that's
that's
all
we
have
today
thanks
again
Brad
for
all
your
efforts
to
get
this
done.
Thank.