►
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
Hi
welcome
this
is
the
what's
next
openshift
roadmap
update,
but
this
is
the
developer
edition.
I've
got
a
whole
group
of
my
pm
friends
on
here
to
cover
a
lot
of
the
developer
topics.
So
with
that
we'll
jump
right
into
it.
A
Just
a
reminder.
So
there's
a
series
of
presentations
that
happen
with
openshift.
You
wrote
mappy,
there's
the
what's
new,
which
talks
about
hey.
This
was
new
in
4
9
and
then
what's
next,
what's
coming
in
the
next
six
12
months,
so
this
is
going
to
focus
on
that
sort
of
up
to
12
months.
So
this
is
the
look
ahead.
Things
may
change.
You
know,
there's
a
lot
of
changes,
the
market
conditions,
other
things
priorities
come
up.
A
So
what
you
see
here
may
or
may
not
happen
just
standard
pm
disclaimer-
and
this
is
the
developer
edition,
so
we're
running
these
alongside
the
main
open
shift
ones.
So,
let's
dig
into
a
little
bit.
I
just
want
to
talk
high
level
sort
of
the
priorities
within
the
developer
tools
area
for
2022.
One
of
the
pushes-
and
this
is
across
red
hat
strategy
overall-
is
around
managed
services,
so
really
trying
to
figure
out
how
we
can
take
everything.
A
We've
done
with
your
open
source
components
and
really
bring
them
together
in
a
single
managed
environment
that
has
a
great
experience
for
delivering
those
pieces.
So
you'll
see
things
that
don't
necessarily
bring
in
like
one-to-one
here's
an
open
source
project
or
an
offering
to
a
managed
version
of
it
becoming
a
wrapping
nose
with
an
experience
that
kind
of
focuses
on
red,
hat's
application
cloud
strategy,
so
sort
of
sitting
above
and
promoting
open
shift.
A
If
you
will
onboarding
continue
to
drive
on
the
dev,
sandbox
been
a
great
way
for
a
lot
of
developers
to
get
their
hands
on
openshift
and
various
installed.
Tools
continue
to
work
on
the
ways
to
improve
the
developer,
getting
the
hands
on
our
our
tools,
software
platforms
and
then
being
very
productive
with
them
earlier
and
as
quickly
as
possible.
Removing
a
lot
of
friction
also
trying
to
continue
to
that's
always
been
a
goal.
Is
that
platform
adoption?
A
A
A
We
complement
with
some
basic
tooling,
all
the
way
from
code
debug
with
code
ready,
workspaces,
vs
code,
plugins,
intellij,
eclipse
extensions
as
well
command
line
tools,
developer
console
and
openshift
odo
cli,
tooling,
build
and
package
through
the
standard
openshift
build
capabilities,
two
wheels,
which
you'll
hear
a
little
bit
about
what's
coming
next,
with
shipwright
helm
and
operator,
enablement
all
the
way
to
enabling
different
technologies
like
serverless
service
mesh
across
the
platform
and
integrations
with
sneak
and
leveraging
some
of
the
other
tools
that
exist
for
providing
secure
software
delivery
across
the
platform.
A
So
there's
a
lot
of
a
lot
of
tools
we've
covered
here,
as
I
mentioned.
That's
this
slide
doesn't
cover
everything.
There's
projects
like
jq
service,
binding
developer,
sandbox,
we'll
talk
about
this
app
studio
code
name.
So
a
lot
of
things
we'll
we'll
cover
that
aren't
part
of
this
slide
itself
with
that
I'll
turn
it
over
to
devon.
B
We
will
be
working
on
adding
the
ability
to
define
and
configure
the
default
registry
at
cluster
level.
So
when
a
tool
will
be
connecting
directly
to
a
cluster,
the
dev
file
registry
will
be
configured
directly
into
the
tools.
We
will
provide
the
offline
support
for
the
file
registry
and
in
order
to
facilitate
the
onboarding
and
the
setup
of
the
toolings,
we
will
be
working
on
solution
allowing
to
analyze
and
detect
the
proper
dev
file
for
a
project
source
code.
B
C
C
So
we
have
different
set
of
products
which
we
have
the
id
extensions
for
for
both
vs
code,
intelligent
eclipse,
tooling,
starting
with
the
openshift
extension.
C
The
other
one
is
having
a
developer
experience
around
intellij
kubernetes.
We
already
have
a
visual
studio
code,
kubernetes
extension,
supported
by
both
red
hat
and
microsoft,
and
we
are
extensively
working
to
have
the
same
feature:
parity
on
the
intelligent
side
of
things
so
that
users
can
do
advanced
cluster
resource
management,
stuff
view
their
logs
directly
and
see
the
local
push
of
their
application
directly
on
the
cluster
using
the
kubernetes
extension.
C
The
next
one
is
to
have
a
support
for
techton
the
same
for
both
ids,
basically
having
the
support
for
extended
pipeline
history,
showing
the
log
retentions
and
even
supporting
the
latest
tecton
hub
on
cluster
for
any
custom
task
catalogs.
C
So
this
will
be
an
ongoing
effect
with
what
we
are
having
with
tecton
cli
and
that
will
be
replicated
on
the
id
itself
so
that,
as
a
developer,
the
experience
should
be
similar.
C
The
other
one
we
are
going
to
work
for
this
year
will
be
to
have
us
remote
container
support
where
users
or
customers
can
run
their
vs
code.
Extensions
within
a
remote
container
inside
the
vs
code
and
that
remote
container
can
be
in
kubernetes
instance
or
open
shift
or
apartment
instance,
and
that
will
allow
them
to
quickly
provision
all
those
scenarios
within
their
containers.
C
One
of
the
important
updates
we
have
for
kodi
studio.
This
has
been
a
very
successful
product
in
the
past
and
we
have
based
on
the
telemetry
and
user
feedbacks.
We
have
decided
to
do
end
of
life
for
quality
studio.
That's
going
to
be
on
april
14th.
C
There
won't
be
any
future
releases
for
code
ready
studio,
but
the
ongoing
effort
will
be
there
on
jboss
tools,
so
whatever
plugins
the
middleware
plugins,
which
are
there
on
kodi
studio,
will
be
supported
with
respect
to
jboss
tools.
So
from
the
customer
point
of
view,
they,
the
experience,
will
be
there.
They
don't
have
to
worry.
C
The
only
update
is
it's
going
to
be
end
of
life
for
quality
studio
and,
as
steven
mentioned,
the
ongoing
efforts
for
dev
file
support
will
be
there
on
the
id
so
that
we
have
the
consistent
approach
beat
on
id
experience
or
developer
console.
D
Sorry,
sorry
hi,
my
name
is
kasturi.
I'm
the
product
manager
for
co-ready
workspaces
onto
already
workspaces
this
year
is
going
to
be
really
action-packed
for
us,
as
we
embrace
a
lot
of
new
things
that
we're
going
to
do
in
the
first
half
or
or
I
should
say
the
end
of
first
half
we're
coming
up
with
a
new
name
but
net
net.
The
product's
core
value
proposition
remains
the
same,
but
it's
just
more
to
align
with
the
branding.
D
The
developer
tools
is
going
to
go,
so
our
new
name
would
be
red,
hat
openshift
dev
spaces,
and
we
are
also
in
the
process
of
revamping
our
architectural
design
with
our
switch
to
their
workspace.
D
This,
which
has
has
already
happened
in
our
upstream
j
and
will
happen
in
korea,
workspaces
probably
end
of
first
half,
and
these
changes
are
essentially
driven
to
make
things
more.
You
know
lighter
flexible
and
kind
of
also
enhance
further
in
terms
of
scalability
and
high
availability.
D
So
that's
something
for
you
to
look
forward
to
and
embrace
it,
as
we
kind
of
you
know,
do
the
switch
along
with
the
new
name,
and
apart
from
that,
there
has
been
some
feedback
from
the
customers
to
make
things
simpler
and
easier,
and
to
that
end
we're
working
constantly,
not
just
with
this
release.
But
we've
been
doing
that
with
couple
of
releases
where
we
would
simplify
constantly
improve
the
sim,
the
install
you
know,
you
know,
making
it
much
simpler
as
possible
and
also
you
know
improving
the
startup
times
of
the
workspaces.
D
We've
heard
from
you-
and
I
think
we
are
also
seriously
working
on
getting
production,
ready,
support
for
vs
code
and
jetpaying
based
editors,
tech,
token,
plugin,
again
something
that's
available
in
the
upstream
and
we're
looking
to
get
that
working
on
code,
ready
workspaces
on
popular
demand
pretty
soon.
D
But
these
are
very,
very
at
a
high
level
on
what
we're
going
to
do.
But
there
is
much
more
for
us
to
do
and
if
you
want
to
kind
of
know,
every
single
line
item
that
kind
of
sums
up
to.
What's
on
the
slide,
then
there
is
a
reference
on
the
backup
slide
which
talks
about
the
quarterly
workspaces
future
in
terms
of
the
in
in
terms
of
the
roadmap.
D
What
I
also
like
to
bring
is
to
your
notices
after
the
2.15
release,
which
kind
of
scheduled
some
time
february
march,
installation
of
quarterly
workspaces
as
an
iron
service,
an
ost
will
be
deprecated
as
replacement
customers
and
install
code
ready
workspaces
from
operator
hub.
Instead,
we're
also
dropping
the
support
for
ocp
versions,
3.1,
4.6
and
4.7.
D
That's
something
I
want
bring
to
your
notice.
Thank
you
and
that's
pretty
much
for
me
over
you,
steven
and
steve.
B
Yeah,
so
on
sorry,
on
our
container
desktop
tooling
initiative,
we
are
going
to
start
a
new
initiative
on
a
developer
container,
desktop
tools
and
this
tool
is
going
to
provide
a
ui
for
managing
containers
and
leveraging
admins.
The
goal
is
really
to
enable
the
developer
to
pull
test
home,
debug
and
inspect
their
containers
and
their
local
environments,
but
also
to
provide
a
bridge
to
kubernetes
and
openshift.
B
The
target
is
really
to
help
the
developers
who
are
working
with
content
containers,
but
targeting
to
run
them
on
a
kubernetes
or
openshift
cluster,
and
also
into
this.
We
we
want
to
enable
self-service
consumption
of
our
managed
services
to
the
developers.
So
it's
something
new.
We
are
starting
to
kicking
off
this
effort
on
this
touring
hope
you
will
hear
a
little
bit
more
in
the
in
the
next
few
months.
A
Thanks
so
with
code
ready
containers
which
fits
into
the
space,
was,
it's
done
a
lot
of
great
work
to
bring
openshift
a
single
instance
onto
the
developer,
desktop
and
has
done
some
recent
work
to
enable
podman
as
well.
What
we're
doing
is
discontinuing
the
code
ready
portfolio
brand.
One
of
those
changes
with
code
ready
containers
is
moving
towards
openshift,
local
and
so
a
lot
of
the
features
you
saw
see
incoming
code.
A
Whether
we'll
be
you
know,
area
is
how
we
align
with
with
other
distributions
of
which,
if
there's
this
project
micro
shift,
which
is
a
smaller
footprint,
that's
being
used
for
some
of
the
pitch
deployments
and
we'll
look
at
how
we
can
leverage
that,
probably
in
a
kind
of
a
community,
supported
kind
of
way,
first,
as
a
way
to
provide
a
slimmer
api
locally.
As
for
those
that
need
it,
and
with
that
turn
over
to
serena.
E
Hi,
I'm
serena
nichols
I'm
going
to
be
talking
about
audio
right
now,
so
audio
is
our
faster
and
straightforward
cli
for
developers
to
write,
build
and
deploy
apps
on
both
open
shift
and
kubernetes,
but
in
2022
we're
going
to
be
releasing
v3,
which
will
start
at
dev
preview.
The
v3
release
will
focus
on
three
major
themes:
onboarding
with
onboarding,
with
guiding
guided
experiences
where
we
are
going
to
be
looking
to
provide
more
in-tool
product
getting
started
so
that
developers
can
get
the
context
help
needed
to
easily
start
with
that
technology
area.
E
Our
third
major
theme
is
around
increased
consistency
between
our
developer
tooling,
with
dev
console
audio
and
openshift.
Connector
stevonn
already
mentioned
that,
where
the
dev
files
are
going
to
provide
that
consistent
layer
between
our
tooling
we'll
also
be
working
on
consistent,
providing
consistent
terminology
between
the
products,
as
well
as
guiding
users
to
other
tools
in
our
portfolio
as
opportunities
for
awareness
and
learning.
So,
for
example,
now
that
you've
deployed
this
go
into
openshift
dev
console
dev
perspective
and
monitor
from
the
topology
view.
B
B
So
we
will
be
working
on
a
continuing
stabilizing
the
apis
and
working
upstream
on
the
service
binding
specification
with
the
faults
from
from
vmware,
and
we
will
also
expand
the
number
of
compatible
and
compliant
services.
So
this
is
a
specification
that
all
the
services
must
be
confirmed
with
the
spec
so
that
they
become
enabled
into
our
tooling.
B
Servicing,
which
will
be
provisioned
through
m
charts,
that
is
also
where
we
are.
We
observe
the
developers
using
quite
a
lot
and
openly
to
to
to
deploy
their
services,
so
we
want
to
enable
service
binding
operator
to
work
with
those
services,
and
we
will
look
at
the
bridge
experience
that
we
can
build
between
secret
management
solution
like
archicad,
vault
and
service
binding
of
adults.
So
how
could
you
inject
secrets
that
are
stored
into
a
into
vault
directly
back
into
into
your
application?.
B
So
that's
for
service
binding
next
slide
on
helm.
So,
as
moit
already
mentioned,
we
have
an
effort
that
is
getting
done
on
integrating
helm
in
the
openshift
connector
plugins.
We
are
also
working
on
the
multi-cluster
support
and
we
we
we
will
be
looking
at
improving
our
approach
on
the
cli
and
providing
mcli
as
an
oc
plugin.
B
E
Thanks
devon
yeah
so
around
the
web
terminal
operator,
currently
we're
still
at
dev
preview,
but
just
to
mention
that
what
this
does
is
it
provides
a
command
line
terminal
feature
inside
of
the
openshift
console.
So
this
was
released
a
couple
releases
ago,
but
we
are
going
to
be
coming
ga
very
soon
over
the
next
year.
We're
going
to
also
investigate
a
number
of
enhancements
for
the
web
terminal,
including
supporting
additional
clis
in
the
terminal,
for
example,.
D
E
And
camel
also
being
able
to
retain
history
within
the
terminal
so
that,
if
your
terminal
time's
out
or
if
you
close
it
and
reopen
it
within
a
single
session,
your
history
history
would
be
retained.
We're
also
looking
into
supporting
multiple
tabs
within
the
command
line
terminal
and,
last
but
not
least,
improved
discoverability
of
the
available
clis.
So
this
image
shows
an
example
of
what
this
may
look
like.
F
Thanks
serena,
so
openshift,
pipeline
openshift
githubs
are
the
real
at
the
center
of
auto
loop,
and
our
mission
is
to
enable
github's
workflows
across
a
wide
area
of
use
cases
within
red
hat
products.
So
initially
the
the
the
closer
to
mind
when
we
talk
about
github's,
workflows,
application,
delivery
infrastructures
code
and
configuration
management,
which
is
what
a
lot
of
our
customers
start
with.
F
But
our
eye
is
really
on
that
wider
number
of
use,
cases
that,
together
with
acm,
acs
and
and
also
ansible,
we
can
enable
across
customers
in
cases
like
configuration,
management
and
edge
when
the
the
number
of
devices
are
large
or
fleet
management
through
githouse
workflows
policy
as
code
and
compliance
as
code.
That
is
extremely
top
of
mind
for
customers,
mlaps
and
and
so
on,
and
this
is
something
that
we
keep
in
mind
as
we
go
throughout
the
year
in
each
quarter.
F
F
So
that's
another
aspect
that
that
will
be
that's
a
common
theme
that
we'll
be
focusing
on
more
specifically
when
we
look
at
openshift
pipelines
pipeline
as
code
or
like
enabling
a
githubs
workflow
for
managing
ci
itself.
That's
a
huge
area
of
focus
for
us
moving
like
hoping
to
to
reach
ga
throughout
this
year,
and
also
some
of
the
other
aspects
of
dealing
with
ci,
like
support
for
approval
and
workflows
and
manual
approval
in
the
middle
of
a
pipeline,
concurrency
control
and
and
features
as
similar
to
that
it
goes
into
the
table.
F
Stake
capabilities
of
pipelines
around
security,
provenance
and
signing
in
attestation
is,
is
an
area
of
focus
both
applied
to
images
produced
through
the
ci
through
a
takedown
pipeline
and
also
the
pipeline
itself,
and
the
task
runs
that
that
are
that
the
pipeline
is
consists
of
when
it
executes,
and
the
last
bit
is
focusing
on
the
operational
bits
from
the
takedown
task.
F
Ecosystem,
and
one
aspect
is
that
we
want
to
make
sure
that
customers
have
a
way
to
create
a
particular
set
of
golden
tasks
that
they
allow
their
developers
or
sre
teams
within
within
the
organization
to
use
and
be
able
to
have
that
exposed
within
the
platform
and
have
that
integrated
rest
of
the
ecosystem.
That
we
have
there's
some
tooling
that
we
have
like
dev,
console
and
cli
and
so
on,
and
also
some
of
the
other
aspects
of
managing
these.
F
These
pipelines
on
on,
especially
across
a
wide
number
of
teams
focusing
on
pipeline
history
and
and
logs,
for
example,
that
right
now
we
will
lean
a
lot
on
on
openshift
logging
stack
and
we
want
to
bridge
some
of
the
gaps
that
exist
there
between
pipelines
and
logging,
the
stack
making
it
easier
for
maintaining
those
locks
or
the
details
of
pipeline
that
are
executed
in
the
past
on
openshift
get
ups.
F
We
just
heard
from
stefan
around
the
hill,
so
we
we
want
to
bring
the
experience
of
using
hell
and
get
us
workflow
to
to
a
much
better
level.
There
are
some
of
the
aspects
of
working
declaratively
with
him
charts
and
git
repo
that
we
hear
from
customers
need
improvement,
we'll
be
looking
at
those
bootstrapping,
argo,
cd
and
github's
workflows
is
something
that
we
have
had
available
since
last
year.
F
In
openshift
guidance,
we
want
to
put
a
lot
more
focus
on
it,
going
forward
to
to
get
customers
easily
get
and
get
started
with
a
git
repo
that
contains
a
particular
layout
that
they
can
push.
Our
applications
to
around
security
supplies.
Secret
secret
management
and
integration
with
secure
managers
is,
is
a
huge
ask.
We
will
be
focusing
a
lot
more
on
that
we
won't
be
supporting
any
secret
manager
ourself,
but
we
want
to
make
sure
that
customers
easily
can
can
use
aggro
cd
with
other
secret
managers
and.
F
Which
is
that
the
most
widely
used
alongside
the
cloud
providers,
key
managers
on
the
operational
experience,
argo
cd
multi-tenancy-
is
something
that
a
lot
of
our
customers
deal
with,
because
most
operational
customers
out
there
are
large
multi-tenant
clusters
and
we
want
to
bring
that
experience
on
par
with
openshift
and
kubernetes
multi-tenancy
argo
cd
has
on
top
of
kubernetes,
has
its
own
multi-tenancy
model.
That
gives
you
two
options.
F
We
want
to
make
those
two
a
lot
more
aligned
and
similar
to
the
rest
of
the
software
that
customers
manage
on
openshift
and
also
provide
a
lot
more
guidance
on
on
managing
cluster
configuration
through
the
githubs
workflows,
not
everything
in
openshift
or
not
everything
about
any
software
really
is
github's
compatible.
So
customers
look
to
us
for
guidance
of
how
to
do
particular
things
that
do
not
sit
well
within
a
git
ops,
workflow,
and
we
will
be
providing
a
lot
more
of
that
kind
of
guidance
throughout
this
year.
G
What
we're
looking
at
there
is
trying
to
figure
out
the
best
way
to
kind
of
begin
deprecating
v1
towards
the
end
of
the
year
and
making
sure
that
we
have,
as
you
get
through
tech
preview,
all
the
things
we
need
for
that
solid
release
there
depth
console
support,
build
triggers
dependency,
caching
performance,
the
things
that
can
are
required
to
turn
this
from
a
you
know,
an
early
project
to
a
full-featured
setup
that
just
facilitates
you
know,
cube
native
builds,
and
you
know,
projects
ship
right,
we're
talking
about
things
like
you
know,
sourced
image,
build
packs,
builder,
etc,
providing
a
path
for
migration
from
builds.
G
We
want
to
build
v2,
be
that
automated
or
you
know,
guides
and
support
for
our
users
there
and
we're
also
looking
at
continuing
our
development
and
iteration
on
various
ci
plug-ins,
one
of
the
things
that
we're
looking
at
there
is
deprecating
support
or
interlocking
support
for
built-in
jenkins.
G
We
found
that
that's,
you
know
very
high
maintenance
and
takes
up
a
lot
of
developer
cycles
and
moving
that
to
a
more
native
c-pass
integration
is
going
to
be
the
way
forward
for
there
also
looking
at
you
know,
focusing
particularly
on
github
actions
as
the
biggest
client
for
ci
plugins,
but
making
sure
that
as
we
build
out
that
and
flash
shutout
further
we're
also
maintaining
the
ability
to
continue
to
support
other
ci
providers
as
your
devops
jenkins
and
so
forth.
G
As
you
keep
going
through
there,
let's
see
enhancing
pipelines.
Cmak
alluded
to
a
bunch
of
this
up
there
in
terms
of
making
sure
that
we
have
the
tools
necessary
to
can
again
make
sure
everything
is
product,
ready,
image,
signing
log
retention,
handling
bundles
and
the
devops
devsecops
integrations
there.
E
All
right,
I'm
back
to
talk
about
the
openshift
console
and
the
developer
experience
inside
of
that.
So
in
2022,
our
main
themes
around
the
developer
experience
in
the
console
focus
around
onboarding
platform
adoption,
as
well
as
addressing
requests
for
enhancements,
we're
focusing
on
a
number
of
new
features,
as
well
as
improved
experiences
in
many
areas.
So
let
me
tell
you
about
some
of
the
things
we're
working
on
in
our
import
from
git
flow
or
bring
your
own
code
flow
you'll,
see
that
we're
now
defaulting
to
secure
routes.
If
that
doesn't
suit
your
needs.
E
things
that
we're
also
looking
at
is
when
deploying
node.js
apps.
We
are
looking
into
enabling
devs
to
enter
optional
parameters
for
the
npm
run
command
regarding
helm,
charts,
we're
going
to
be
looking
into
providing
a
quick
start
in
the
home
catalog
to
show
the
users
how
they
create
a
home
chart
repository
which
is
namespace
scoped
via
yaml
yamo,
which
will
pull
in
additional
helm
charts
into
that
project
following
that
will
provide
a
form-based
experience
to
accomplish
that
same
user
flow.
E
Now,
let's
dive
into
application
comportability,
once
you've
built
your
application
in
the
dev
console
and
tweaked
things
to
work
exactly
as
you
like,
we're
working
on
a
number
of
features
which
will
allow
you
to
move
your
application
from
your
current
project
to
another
project
or
even
to
another
cluster,
or
even
check
it
into
your
git
repo.
As
some
of
you
know,
we
already
do
have
the
ability
to
export
your
application
to
yaml
from
the
topology
view.
E
If
we're
thinking
about
the
navigation
and
the
developer
perspective,
we
already
provide
the
way
for
a
user
to
add
custom
nav
items
there,
but
the
feedback
that
we've
heard
is
that
users
want
to
reorder
those
custom,
nav
items
so
we're
looking
into
that
and
regarding
our
topology
view,
we're
always
looking
at
ways
to
make
that
more
efficient
and
usable,
but
we're
also
spending
some
time
to
address
some
scalability
and
performance
concerns.
These
won't
only
be
addressed
by
code
changes,
but
also
by
some
changes
in
the
experience.
E
Last
but
not
least,
regarding
design
desirability
we're
working
on
we're
working
hard
on
providing
a
dark
theme
across
all
of
openshift
console
now.
Finally,
let's
do
do
a
deep
dive
into
portfolio
enabling,
as
you
know,
developer
console
is
allows
a
number
of
features
by
itself,
but
as
we
install
additional
operators,
we're
really
unlocking
additional
features.
E
We're
also
going
to
look
into
the
ability
to
have
kubernetes
kubernetes
services
as
syncable
resources
when
working
with
channels
and
brokers,
and
we
are
also
providing
a
event.
Sync
catalog,
as
well
as
kafka
sync
support
when
looking
at
openshift
pipelines
as
ciamec
discussed
many
of
these
items
previously,
some
of
the
workflows
that
he
discussed
we'll
be
looking
at
supporting
in
the
console
in
the
future.
E
So
we
already
do
have
some
level
of
integration
with
techton
hub
with
a
pipeline
builder,
but
we're
looking
into
supporting
local
tecton
hub
instances
and
being
able
to
do
that
from
inside
the
console.
H
So
many
of
you
are
familiar
with
the
developer
sandbox,
where
it
had
openshift.
So,
let's
talk
about
you
know
the
recap.
For
last
year
it
was
launched
in
2021.
So
overall
you
know
we
have
launched
some
new
things
in
q1.
We
did
a
you
know
our
data
science
fans
were
probably
seeing
the
rhodes
sandbox,
so
it
enables
to
create
data
science
models
without
having
to
provision
openshift
on
your
own.
It
comes
bundled
with
the
entire
stack
of
data
science.
H
We
ran
a
hackathon
for
our
managed
kafka
service
and
the
developer,
sandbox
and
openshift
experience,
and
it
was
very
well
received
in
apac
with
about
you,
know:
230
participants
across
nine
countries,
so
in
the
continuously
delivering
new
things
so
that
we
can
have
more
folks
come
in
onto
the
sandbox
to
kind
of
try
out
our
portfolio,
try
out
the
experience
and
also
use
it
to
you,
know,
kind
of
demo
it
or
set
up
projects
for
customers.
H
You
know
if
you're
a
reseller
next
slide,
please,
when
we
look
at
you
know
the
trials
from
an
openshift
perspective.
Developer
sandbox
is
the
highest
system
that
is
used
to
try
out
openshift
and
the
good
news
is.
It
also
leads
to
the
follow-up
journey,
which
is
okay
after
the
opera
sandbox.
Can
we
now
go
try
out
either
a
managed
openshift
or
openshift,
which
is
self-managed
on
public
or
private
clouds,
and
then
that
leads
to
a
sales
opportunities
and
closure
of
you
know,
maybe
even
existing
opportunities,
and
so
we
can
see
that
developer.
H
Sandbox
is
influencing
new
trials
of
our
platform
and
also
influencing
you
know
single
year
bookings
for
red
hat
next
slide.
Please.
H
So,
what's
coming,
you
know
in
the
next
few
months
is
we're
going
to
be
on.
You
know,
adding
more
and
more
into
the
developer
sandbox.
We
are
onboarding
the
openshift
pipelines
operator
we're
on
boarding
the
database
as
a
sas
operator,
especially
with
the
launch
of
you
know.
The
road
service
coming
up
pretty
soon
we'll
be
merging
the
rhodes
sandbox.
Now
that
we've
had
it
out
into
one
uber
sandbox,
which
is
going
to
be
the
current
sandbox
that
we
have,
but
now
it's
going
to
have
a
lot
more
in
it.
H
So
now
you
can
imagine
the
customers
can
not
only
create
data
science
models,
they
can
also
create
applications
that
consume
those
models
and
even
run
the
pipelines
to
you
know,
run
a
few
builds
and
sample.
You
know
sample
tasks
that
they
want
to
automate
the
end-to-end
part
of
the
what
it
takes
to
deliver
a
data
science
model
into
an
application
so
very
exciting.
You
know
it's
going
to
be.
You
know
a
much
broader
reach
across
our
red
hat
customer
base,
continuing
on
the
free
to
feed
journey.
H
What
we
are
serena
mentioned
about
the
the
ability
to
export
an
application
and
then
import
into
a
cluster,
we're
going
to
be
onboarding
those
capabilities
into
the
sandbox
and
then
tying
it
back
into
our
console
redhead.com,
so
that
you
could
actually,
you
know,
come
into
the
sandbox,
create
an
application
export.
It
create
a
new
cluster.
Let's
say
it's
a
rosetta
cluster
on
aws
and
then
kind
of
import,
the
you
know
the
application
directly
into
there
so
providing
a
free-to-feed
journey
there
to
increase
customer
acquisitions.
H
We
are
going
to
be
working
on
a
few
things
on
the
product
side,
most
more
on
the
marketing
side.
One
of
the
things
that
we
are
targeting
with
the
product
side
is
having
an
activation
code
based
targeted
subscription
so
that
you
could
have
a
special
event
where
you
run,
you
can
have
a
code
that
you
can
share
with
everybody.
H
You
could
say
you
know
code
can
support
up
to
250
new
sign
ups,
keep
it
valid
for
the
next
24
hours
and
then
that
way
we
can
now
find
you
know
who
came
in
for
a
particular
event
make
sure
they
all
come
into
the
same
developer.
Sandbox
environment
in
terms
of
the
cluster,
and
then
you
can,
you
know,
run
promotions
and
and
the
subscribers
can
avoid
having
to
do
phone
verifications
and
things
like
that.
H
They
can
just
come
in
directly
because
you
have
shared
an
activation
code,
so
we're
kind
of
working
on
that
capability.
Next
slide,
please
so
app
studio.
I
don't
know
how
many
of
you
have
heard
of
it.
It's
a
code
name.
So
please
don't
go
by
the
you
know
by
the
the
title,
but
it
is
targeting
a
managed
developer.
Experience
that
is
going
to
be,
you
know
focused
on
you
know,
delivering
a
lot
more
of
our
app
cloud
strategy,
so
you
know,
but
this
is
the
first
step
into
it.
H
So
I'd
like
to
share
some
details
about
it,
you
know
with
a
brief
overview,
so
you
know
we
are
working
through
the
you
know
the
flows
that
as
a
developer,
when
you're
creating
a
new
application,
you
have
an
existing
application.
There's
a
flow
that
takes
to
go
from
an
application
to
a
scaled
out.
Deployment
of
the
application
across
a
multi-cloud
platform
starts
from
wanting
to
create
an
application
all
the
way
to
packaging.
Connecting
it
to
services
and
can
affordably
continuously
delivering
it
onto
the
cloud
platform
that
is
suitable
for
that
application.
H
Next
slide,
please,
and
for
that,
as
we
all
know,
there's
quite
a
few
steps
that
developers
have
to
go
through
and
some
of
these
steps
you
have
to
do
them
very
often,
and
some
of
the
steps
are
highly
complex
and
may
not
have
to
be
done
as
often
right,
but
it
starts
by.
How
can
I
create
a
secure
container?
You
know
from
the
source
code
that
I
have
all
the
way
down
to.
How
do
I
deploy
it
to
all
the
cloud
platforms?
H
How
can
I
access
the
data
that
I
need
to
kind
of
fix
issues
when
it
comes
up
when
the
application
is
running
across
the
different
cloud
platforms,
and
so
there's
a
lot
of
steps
that
need
to
happen
and
for
developers
there's
a
lot
of
technology
complexity
and
a
lot
of
the
know-how
that
has
to
be
kind
of
learned
and
built
in
before
they
can
go
from
zero
to
60
miles
an
hour
so
currently
the
zero
to
60
honestly
just
takes
a
long
time.
H
So
what
we
are
announcing
app
studio
at
red
hat
summit
is
a
hosted,
fully
managed
experience
to
solve
some
of
these
problems.
You
know
basically
enable
developers
to
build
full
stack
applications,
including
java,
easily
connect
to
all
the
leading
cloud
services
and
tools
that
are
that
they
are
used
to,
especially
in
the
cloud
world,
adopt
certain
devsecops
practices
without
really
becoming
an
expert
in
devsecops
and
deploy
to
any
cloud
platform
of
choice.
That's
the
mission
that
app
studios
is
working
towards
and
to
make
it
easy.
H
So,
let's
not
let
the
developers
kind
of
fumble
around
figuring
out
and
how
do
I
create
a
container
that
is
going
to
be
secure,
provide
seamless,
integrations,
kind
of
hide
the
apps
abstract
out
the
technology
and
make
it
easy
for
them
to
do
the
work
that
they
need
to
do
without
having
to
become
an
expert
in
the
underlying
pipeline
products,
skill,
ops
products,
the
platform
of
openshift
itself
like
we
are
just
basically
creating
a
developer
experience
which
is
managed
by
us
and
then
in
the
end,
give
them
a
single
plane
of
glass
for
all
your
applications
across
the
software.
H
So
in
the
beginning,
what
we're
gonna
do
we're
gonna
target
certain
kind
of
applications
which
are
you
know,
suitable
for
app
studio
right,
so
full
blown
front
and
back
and
always
there,
but
like
distributed
micro
services
in
applications
that
span
across
cloud
platforms
and
geos
applications
that
are
basically
going
to
be
scaled
up
with
demand
that
comes
in
next
slide.
Please.
H
At
a
high
level,
when
you
look
at
the
architecture,
what
this
means
is
customers
can
bring
in
the
services
and
the
tools
that
they
are
used
to,
that
they
want,
and
they
could
be
tools
and
services
given
to
them
by
red
hat
by
the
cloud
vendors
themselves
by
other,
even
isvs,
like
you
know,
gitlab
and
hashicorp
and
and
github,
and
then
you
bring
in
the
experience
that
is
on
consoleredhead.com
and
you
can
have
a
layer
in
the
middle
that
ties.
H
This
makes
it
very
easy
to
tie
these
applications
that
you
are
creating
with
these
services
and
tools
that
you
want
to
consume,
have
a
iterative
environment.
So
you
don't
have
to
worry
about
creating
a
kubernetes
or
an
open
shift
environment
just
to
kind
of
try
out
your
application.
It
comes
bundled
with
it.
You
just
come
in.
You
start
running
your
application,
it
will
iterate
you
want.
H
You
can
then
commit
to
basically
buying
open
shift
environments
when
you're
ready
right,
and
so
it's
not
like
you
have
to
go,
buy
one
on
day,
one
just
so
you
can
iterate
over.
The
application
will
give
you
that
it
may
take
you
months.
It
may
take
you
days
it's
up
to
the
customer
and
then
once
you're
ready
when
you
deploy
your
applications.
You
know
you
can
basically
pick
and
choose
the
cloud
platforms.
H
You
can
pick
and
choose
the
openshift
environment
that
you
want
on
top
of
it,
and
then
you
know
we
are
working
towards
a
hybrid,
app
cloud.
The
compute
part
of
it
where
we
abstract
out.
You
know
all
these
things
and
we
basically
are
just
in
a
customer,
can
literally
just
pick
and
choose
certain
placement
rules
and
requirements,
and
we
just
go
deploy,
irrespective
of
the
of
the
underlying
cluster
excite,
please
so
to
get
there
an
ambitious
project
and
you
know
we're
going
to
be
doing
it
in
a
very
measure
way.
H
Iterative
way,
it's
managed
it's
hosted.
So
the
good
news
is,
we
don't
have
to
follow
product
release
cycles.
We
wanted
to
make
it
really
fast
and
iterative.
Take
customer
feedback,
bring
it
in
deliver
the
next
capability
at
the
end
of
every
sprint.
So
we're
going
to
start
by
launching
a
private
preview
around
summit
timelines
and
we
want
to
provide
certain
capabilities
in
that
the
key
one
being
you
should
be
able
to
create
an
app
iterate
over
it
in
the
bundle,
sandbox
create
a
rosa
cluster
and
just
deploy
it
to
rosa.
H
So
now
you
have
a
multi-cluster,
multi-cloud
environment
experience
right
on
day,
one
of
private
preview,
and
then
we
go
past
it
right.
A
Thanks
brog
yeah,
we
come
to
the
end
here.
Some
additional
resources,
we've
done
the
four
nine.
What's
new
developer
edition,
so
we're
looking
at
doing
a
410
one
coming
up
we're
gonna
look
out
for
that.
A
We'll
update
some
links
here
as
we
have
them,
but
if
you
do
want
to
reach
out
there's
the
devtools
pm
mailing
list,
which
is
covers
everyone
on
this
call
and
yeah
thanks
to
kasturi
moet
barag
rob
serena,
savan
and
ncomic
for
pulling
this
together,
and
if
you
do
want
the
gory
details
of
all
the
different
things
that
are
happening,
you
can
look
in
the
back
up
of
the
slides.
We
have
the
detailed
road
maps
for
all
the
different
areas
we
covered
that
cover.
A
Basically
the
quarters
or
more
or
less
the
rest
of
this
year,
as
I
mentioned,
continues
to
be
a
a
growing
focus.
Things
may
change
things
expand
a
lot
of
great
stuff
here.
So
please
reach
out.
If
you
have
any
questions,
if
you
have
any
feedback,
we'd
love
to
hear
it,
and
thanks
for
listening
and
watching.