►
From YouTube: OCB: AMA on TOSCA the Topology and Orchestration Specification for Cloud Applications - Tal Liron
Description
TOSCA, the “Topology and Orchestration Specification for Cloud Applications,” is a standard for cloud application and NFV (Network Functions Virtualization). TOSCA enables users to deploy and orchestrate the lifecycle of application and network services across multiple clouds (and other environments). The TOSCA language models and validates cloud topologies using reusable and extensible objects. It allows architects to focus on application design and requirements without being bogged down by the ever-changing specificities of the infrastructure. TOSCA is vendor independent.
This briefing will review the current state of TOSCA standard, how it has evolved over time, and also give you a preview of the new features added to TOSCA version 2.0 (due to be released by the end of 2020) which will further align it with modern development paradigms, including cloud-native and microservices.
A
All
right,
everybody
welcome
back
again
to
another
openshift
commons.
Ask
me
anything
ama
session,
as
we
are
want
to
do.
On
mondays,
we
like
to
have
upstream
projects
other
technology
initiatives
and
people
with
new
things
to
talk
about,
to,
come
and
and
tell
us
a
little
bit
about
where
they're
at
and
all
those
kinds
of
good
things.
And
today
we
have
a
group
of
folks
that
I've
been
involved
with
in
the
past
tosca,
which
is
the
topology
and
orchestration
specification
for
cloud
applications
and
that's
a
mouthful
and
I'm
going
to.
A
Let
them
explain
what
that
is
and
how
that
intersects
with
the
openshift
ecosystem
and
we'll
have
some
live
q
a
at
the
end.
But
today
I'm
really
pleased
to
have
with
us.
Chris
lowers
who's.
The
tosca
chair
and
the
ceo
of
yubi
city,
ubicity
and
tal
laron
who's,
a
colleague
of
mine
here
at
red
hat
and
we're
gonna,
have
a
bit
of
a
demo
and
a
setup
about
what
topasca
is
and
then
we'll
roll
into
q
a
fill
the
hour
with
all
kinds
of
goodness.
So
chris
and
tall
take
it
away.
B
Thank
you.
So
thanks
diane
hi
everybody,
so
this
is
fun
I'll.
I
in
the
in
the
spirit
of
the
ama,
will
keep
things
I
think
pretty
loose.
I
will
mostly
focus
on
on
a
demo
and
kind
of
show
you
through
example,
where
we
are
right
now
with
tosca
and
specifically
on
kubernetes,
but
we
do
have
a
bunch
of
slides
too
we're
gonna
kind
of
race
through
them.
B
Recently
we
did
a
webinar
to
introduce
tosca
to
the
world
and
there's
a
recording
of
that
or
reintroduce
the
task
to
some
industries,
because
some
industries
are
working
of
very
strongly
with
tasks
and
have
been
for
a
while.
So
we'll
be
able
to
share
a
link
to
that
video
too.
So
you
can
get
the
kind
of
more
general
overview,
but
I
hope
that
today
would
be
more
hands-on,
so
tosca
has
been
around
since
2014.
B
So
I
I
wish
I
could
do
a
show
of
hands
here
of
who
who
participating
has
heard
of
tosca
before
or
or
even
used
it.
We
won't
do
a
show
of
hands,
but
I
think
if
people
have
been
involved
with
tosca
for
a
while,
they
probably
know
tosca
as
solution
for
cloud
portability.
That's
kind
of
how
people
understood
it
for
a
while.
B
So
if
any
of
you
use
openstack
and
heat
on
openstack
heat
has
its
own
templating
language,
a
kind
of
declarative
way
to
define
your
resources
and
then
the
heat
orchestrator
can
actually
take
your
intent,
intent
based
models
and
turn
them
into
an
actual
running
deployment
right,
create
its
own
kind
of
internal
workflows.
Internally
and-
and
I
think
people
thought
of
tosca
well,
tosca
is
kind
of
like
heat,
but
it's
not
openstack
centric,
but
rather
it
can
work
with
many
cloud
platforms
according
to
whatever
implementation
would
support
oscar.
B
Now,
that's
not
wrong.
That's
not
entirely
a
wrong
way
to
view
tosca,
but
I
think
it's
very,
very
incomplete
and
actually
in
some
ways
it's
not
even
the
most
interesting
part
about
tosca
tasna
aims
for
cloud
portability,
but
I
think
it's
not
so
much
in
that
you
would
have
common
models
for
various
clouds.
B
Installer
that
could
use
tosca
to
model
your
data
center
and
yeah
we're
gonna,
I'm
gonna
kind
of
race
through
these
slides
a
little
bit
and
and
we'll
share
them
too.
So
you'll
be
able
to
to
see
everything.
But
I
just
wanted
to
give
you
an
a
high
level
look
at
of
how
taska
looks
before
I
really
jump
into
a
hands-on
demo
and
at
this
point
I'll
introduce
chris
chris
lowers
my
my
colleague
here
and
hi
chris.
B
C
That
way
was
something
that
happened
a
couple
years
ago
in
the
telco
space,
where
network
functions
virtualization,
I
think
drove
the
need
for
a
technology
and
a
approach
for
automating.
The
deployment
of
virtual
network
functions
in
the
in
in
telco
clouds
and
as
that
industry
started
looking
at
technologies
for
how
to
do
that.
C
C
B
Yeah,
that's
true
so
I'll
just
add
two
more
or
three
more
quick
ones.
So
one
of
them,
you
know
I'm
it's
not
it's
not
just
that
costco
can
be
used
in
kubernetes.
I
actually
think
that
tosca
has
a
huge
value
proposition
for
for
kubernetes
in
terms
of
moving
it
forward.
So
I've
made
a
presentation
to
the
cncf
telco
user
group,
tug,
which
I
think
went
pretty
favorably
in
terms
of
and
here's
the
provocative
statement.
Tosca
can
actually
replace
helm
and
should
replace
helm.
B
If
you
ask
me,
there's
been
a
kind
of
history
in
kubernetes
of
slowly
evolving
its
extensibility.
This
is
something
that
openshift
embraced
very
strongly
through
the
operator
sdk,
but
we
know
that
in
kubernetes
you
can
create
custom
resources
that
extend
the
the
basic
language
of
the
system.
Now
tosca.
A
B
Object-Oriented
language
is
a
perfect
fit
for
that,
and
we
we
see
within
kubernetes
a
kind
of
evolution
right
now.
I'm
sure
all
of
you
know
you
can
create
a
crdn
kubernetes
that
uses
a
schema
right.
It
copies
the
open
api
of
e3
schema.
So
you
can
you,
you
can
define
a
a
very
good
structure
for
your
custom
resource
now.
Tosca
can
do
that
so
much
better
task
has
been
doing
that
since
the
beginning
and
importantly
in
tosca
2,
it's
not
just
a
collection
of
resources,
but
it's
a
topology
relationships
in
tosca.
B
The
connect
nodes
are
first-class
citizens
and
they
can
be
modeled
themselves,
so
you
can
have
relationships
that
are
say.
Connectivity
relationships
have
to
do
with
say,
service
meshes,
but
you
can
have
relationships
that
are
more
about
ownership
or
or
security
or
or
forming
things
in
group
or
data
connectivity
data
flows.
B
B
B
B
I
have
two
kubernetes
clusters
running
here
and
here
we
go
okay,
so
I
have
two
kubernetes
clusters
running
here:
one
they're
running
a
mini
cube
and
one
of
them
is
going
to
be
simulating.
Maybe
I
call
the
central
data
center
and
the
other
one
is
the
edge
data
center
and
I've
pre-installed,
both
of
them
with
the
cube,
vert
and
multis.
Multis
is
a
very
important
part
of
the
demo
I'll
be
showing,
but
I'm
going
to
start
with
a
quick
hello
world
just
so
you
can
get
a
sense
of
how
asco
works.
C
B
I
love
this
font
too.
Anybody
wants
tips
on
the
font.
Let
me
know
I'll
be
happy
to
share
with
you
it's
my
favorite,
so
the
tosca
is
a
yamo
based
language,
but
it
is
actually
a
very
sophisticated,
object-oriented
language
too.
So
you
can
create
types
you
can
inherit
types
you
can
override
and
within
the
types
there's
actually
a
rich
set
of
structures
that
are
really
designed
around
cloud.
B
So
it's
not
a
general
purpose,
object,
oriented
language,
it's
very,
very
much
tuned
towards
modeling
cloud
resources
and
again
cloud
resources
of
different
kinds,
workloads,
infrastructure
systems
platforms.
So,
let's,
let's
look
at
the
hello
world
which
is
based
on
kubernetes,
so
ignore
the
metadata.
For
now
this
is
some
extra
stuff
for
the
demo
that
we
don't
need
to
do
now,
but
I'm
importing
in
my
imports
I'm
importing
two
different
profiles.
B
One
profile
is
a
kubernetes
profile
that
models,
the
the
kubernetes
resources,
we're
going
to
see
it
and
the
other
one
is
an
orchestration
profile
which
has
some
extensions
for
the
orchestrator
that
we'll
be
using
today
that
allow
it
to
run
certain
configuration
scripts
on
these
resources.
After
they
they
start
up.
We're
going
to
declare
for
this
hello
world,
a
single
node,
we'll
call
it
an
application,
so
it's
a
node
type
and
in
tosca
we
we
have.
Every
node
has
capabilities,
which
are
things
that
it
exposes.
B
B
It
has
a
deployment
which
we
know
a
kubernetes
resource
and
it
has
a
load
balancer.
The
load
balancer
is
actually
a
kubernetes
service,
but
what
the
profile
here
has
a
type
that
derives
from
a
basic
service
and
just
defaults
to
all
the
the
load,
bouncer
behavior
and
that's
kind
of
all
I
needed
to
do
here.
B
So
here
I'm
calling
an
input,
I'm
getting
one
of
the
inputs
that
I
get
here
for
the
namespace
I'm
giving
this
a
label
and
then
for
the
deployment
I'm
giving
it
a
container
and
here
again
interesting
for
the
image
I'm
actually
using
the
tosca
get
artifact
function
to
get
an
image
to
get
an
artifact
that
I'm
attaching
here
below.
So
I
have
a
section
called
artifacts
and
I'm
having
an
image,
and
I
have
a
kubernetes
container
image
now.
B
One
thing
is
already
interesting:
you
can
see
well,
actually
this
single
node
here
involves
two
different
kubernetes
resources
in
this
case,
so
it's
a
deployment
plus
a
service,
here's
the
web
service,
the
load,
balancer
and
here's
its
ports.
Now
what's
interesting
here,
you
know,
I
I
think
about
my
node
in
terms
of
involving
both
of
them.
I
modeled
it
this
way
I
decided
to
create
a
workload
that
includes
both
of
them.
I
could
have
done
things
differently.
B
I
could
have
separated
them,
but
pascal
lets
me
model
my
my
domain,
my
application,
my
workload
according
to
the
paradigms
that
I
want
to
use
right.
So
if
I
want
to
deploy
this
node
template
turn
it
into
an
actual
node,
it's
all
at
once.
It
includes
both
the
the
deployment
and
the
service
that
was
up
to
me.
B
I
could
have
modeled
things
differently,
that
that's
how
I
created
my
my
node
type
above
and
we're
going
to
see
an
example
that
that's
much
more
sophisticated
than
this
one,
but
I
wanted
to
get
this
hello
world
going.
So
the
the
artifact
is
also
a
very
interesting
feature
in
tosca,
where
I
can
pasta
defines
a
packaging
format
called
the
csar.
B
Dsar
stands
for
cloud
service
archive.
It's
a
zip
file
that
includes
this
ammo
that
we're
looking
at
right
now,
but
includes
other
artifacts
that
I
also
want
to
include
so
for
this
hello
world.
I
decided
to
to
actually
incorporate
a
tarball
of
the
container
image
and
then
the
orchestrator
will
make
sure
to
register
it
on
an
inventory
so
that
inventory
could
be
quay.
It
could
be
harbor,
it
could
be
any
docker
or
oci
compatible
repository.
B
Now
I
don't
have
to
use
that,
of
course,
if
I
want
to
set
my
repository
else
well
here
an
image
I
can
just
give
it
a
string
name
right,
but
I
wanted
to
demonstrate
that
I
can
actually
package
have
a
self-contained
package
which
includes
really
everything
you
need
to
deploy
the
application.
So,
let's
look
at
how
that
zip
file
looks
so
I
have
here
the
hello
world
dsar
file,
the
font
is
a
little
small
there.
I
hope
visible
enough.
B
So
if
I
open
the
zip
file,
I
do
see
this
hello
world
yaml
that
we're
seeing
above
I
see
profiles
that
it's
importing.
So
these
things
that's
importing
the
kubernetes
profile
and
the
orchestration
profile.
I
just
included
them
inside
the
csr
file,
and
then
I
have
the
artifacts,
and
here
I
have
scripts
that
it
uses
for
configuration,
and
I
have
here's
the
tarball
of
the
container
image,
pretty
small.
B
Hope
you
excuse
me
for
that
and
yeah.
So,
oh,
I
should
probably
say
what
am
I
using
actually
to
orchestrate
this.
So
I
I
am
using
this
turan
dot.
Turon
dot
is
a
kubernetes
operator
that
basically
allows
you
to
use
toscan
kubernetes,
that's
entirely
what,
but
it's
meant
to
do
so.
It's
as
an
operator.
It
runs
in
the
cluster.
It's
very
lightweight
written
in
go
open
source
and
I
wrote
it
and
yeah.
So
so
what
it
does
it
takes
that
task
and
really
translates
it
into
those
kubernetes
features.
B
B
B
We're
used
to
that's
the
registry,
where
it
stores
the
container
images
in
this
case
I'm
running
just
for
demo
purpose
the
the
default
docker
registry.
But
for
you
know
real
deployments,
you
would
want
to
use
something
like
clay
probably
and
it
can
run
external
to
the
cluster
somewhere
else.
That's
not
a
problem,
so
we
have
turn.running
and
let's.
B
B
B
B
Here
we
go,
so
we
have
the
hello
world
running
on
kubernetes
and
yeah.
It
actually
added.
There's
a
configuration
script
that
configured
it.
If
I
go
back
to
the
tasker
file,
you
can
see
that
here
I
created
an
output
which
is
the
url
and
what
the
output
does.
So
there
are
some
tasks
of
functions
here
that
it
concatenates
http
and
it
gets
an
attribute
which
is
the
live
running
ingress
from
that
service
and
just
adds
port
80
to
the
end.
B
So
I
could
create
a
really
nice
output
from
it
and
I
didn't
want
to
show
you
that
configuration
script,
that's
what
it
does
as
an
artifact
scripts
yeah.
So
the
the
configuration
script
there's
some
bash
work
here
here
that
just
adds
that
part
of
tosca
node
with
the
node
template
name
and
that's
what
we
saw
here.
So
the
node
template
is
hello
world
again
just
for
demo
purposes.
B
B
It
has
a
way
to
model
your
application
and
instead
of
the,
I
would
like
to
say
really
terrible
text
templating
that
you
get
in
helm
as
a
way
to
create
to
generate
yaml.
Here
you
have
a
language
that
lets
you
model
in
an
object-oriented
way.
Your
resources,
whether
they're,
logical
or
physical,
but
also
has
all
these
built-in
functions
that
allow
you
to
get
live,
live
data
and
work
with
it
directly.
So
we're
not
doing
text
templating
here
we're.
B
Actually
we
we
have
a
language
that
it's
declarative,
but
it
also
has
a
programmatic
functionality
to
it.
So
now
I'm
going
to
show
you
a
richer
demo
than
this.
That
was
just
a
hello
world.
I
really
want
to
show
you
how
far
we
can
go
with
this.
So
I
have
a
demo
here
of
a
telephony
network
service,
so
I'll
say
quickly.
B
So
I'm
an
engineer
at
red
hat,
but
I
work
at
the
cto
office,
specifically
on
the
on
on
the
telco
industry
and
working
on
orchestration
for
telco
telco
is
a
complex
user
of
clouds.
There's
a
lot
of
requirements
that
you
see
them
in
enterprise
applications
too,
but
the
networking
aspects
are
very
important,
so
multis
is
critical,
a
way
to
create
data
planes
that
are
accelerated
in
some
way
through
through
hardware.
You
need
to
configure
these
external
boxes.
B
Sometimes
these
high
performance
switches,
smart
switches,
smart
knicks,
there's
a
lot
going
on
in
in
in
telco.
So
the
example
I'm
actually
going
to
show.
You
is
a
multi-cluster
example,
so
there's
a
central
cluster
in
an
edge
cluster
and
it's
running
telephony
software,
specifically
asterix
pbx,
which
is
a
pretty
fun
open
source
pbx
and
I'm
going
to
demonstrate
having
there's
a
separate
data
plane
that
uses
multis.
B
B
So
that's
kind
of
the
diagram:
let's
see
how
it
looks
in
tosca,
so
this
is
the
actual
high
level
telephony
network
service
and
you
can
see
it
imports
three
different
profiles.
So
it
has
the
network
service
profile,
which
has
a
bunch
of
pre-made
types
for
that
the
telephony
profile
and
that
orchestration
profile
that
we
used
before
for
the
configuration
interfaces.
B
This
is
a
very
high
level
look,
so
we
have
our
node
templates.
We
have
two
different
node
templates
that
are
telephony,
pbx
types
and
they
have
some
endpoints.
These
endpoints
are
actually
telephone
numbers,
so
they're
sip
telephone
numbers
and
there's
a
trunk
capability.
So
there's
an
sip
trunk
that
uses
that
data
plane
and
to
connect
to
the
other
terms.
So
here
I'm
specifying
the
requirements,
and
this
is
where
I
get
into
the
topology
and
forming
relationships.
B
Then
I
have
the
data
plane,
which
I
modeled
as
a
separate
node,
and
it's
just
of
type
network
link.
So
when
you
look
at
all
this,
you
say
well,
this
is
very
high
level.
You,
you
didn't
specify
any
technology.
There's
nothing
here
about
q,
verbs!
There's
nothing
here
about
multis!
These
are
a
high
level
concept
of
modeling.
What
you
want-
and
yes
this
is
the
point.
So
how
does
this
actually
turn
into
those
real
resources?
Are
they
abstracted
away?
B
No,
what
what
tosca
allows
me
to
do
here
is
actually
substitute
these
nodes,
these
node
templates
with
a
real
implementation.
I'll
show
you
how
that
real
implementation
works
and
that
substitution
happens
through
these
policies
that
I've
defined
here.
So
I
have
a
provisioning
policy
that
tells
me
how
to
provision
those
specific
nodes,
I'm
telling
it
which
site
I
want,
I'm
telling
it
what
kind
of
profile
I
want,
and
this
this
provisioning
policy
is
its
own
type
part
of
the
orchestration
package
profile.
B
B
So
what
is
large
and
what
is
small,
the
small
one
is
this
asterix
cnf,
so
I
have
an
asterisk
cnf
packaged
as
a
a
csr
file,
and
here
I
go
back
to
this-
looks
again
like
that
hello
world,
that
we
looked
at
so
again,
I'm
importing
the
kubernetes
profile
defining
all
these
capabilities.
There's
a
load
balancer,
there's
a
con,
a
connectable
that
is
a
virtual
link
in
the
nfv
world.
We
call
to
a
to
the
data
plane
and
then
I
actually
create
again
the
the
kind
of
low-level
kubernetes
stuff
here.
B
So
there's
a
deployment,
here's
a
service-
and
I
know
it,
looks
ugly
there's
a
lot
of
things
you
need
to
do
in
terms
of
opening
ports
udp
ports
to
get
the
cif
to
work
here,
I'm
putting
annotations
for
multis.
So
those
of
you
who
are
familiar
with
multis
these
are
the
standard
or
the
in
progress,
standardizing,
cncf
annotations
and
I'm
getting.
This
live
from
the
data
plane.
So
I
can
get
the
exact
name
of
the
the
multis
network
from
there.
B
Here's
the
containers
once
again,
I'm
packaging,
the
container
image
here
and
the
csr
file
using
the
get
artifact
function
and
there's
a
bunch
of
stuff
here
configuration
files
for
asterix.
But
you
can
see
it's
basically
a
standard
kind
of
kubernetes
deployment
and
how
does
the
large
profile
work?
So
the
large
pro
back
profile
here
is
the
vnf,
and
this
is
a
bit
more
complicated
because
in
this
case
we're
actually
importing
a
mariadb
operator.
B
So
there's
a
modeling
for
that
to
create
a
separate
database
for
it
and
then
it's
it's
importing
kubevert
to
to
create
the
virtual
machine.
So
now
I
have
a
bit
more
complex
node,
just
because
qvert
is
a
little
bit
more
complicated.
So
I
defined
the
virtual
machine
data
here
I
have
to
create
a
container
disk.
I
have
to
create
a
cloud
in
its
disk
as
well
to
mount
to
to
initialize
that
virtual
machine
and
the
cloud
in
the
disk
itself
is
uses
an
artifact,
so
it
has
get
artifact
and
it's
encoded
in
base64.
B
So
so
there
are
some
keyword,
specific
things
here
that
I
won't
go
to,
but
here
all
the
artifacts
attached
and
there's
the
configuration
files.
There's
the
you
need
a
private
key
and
a
public
key
for
a
virtual
machine
things
that
you
don't
need
with
containers
in
in
kubernetes
and
here's
the
the
database
node
from
mariadb.
B
So
it's
it
just
has
a
type
that
it
already
has
a
lot
of
what
it
needs
from
the
type,
but
I'm
just
specifying
specific
information
for
it,
like
kubernetes
labels,
etc
and
database
username
and
password
hard
coded
in
this
case,
all
right.
Let's
deploy
all
this
so
I'll
go
once
again
to
my
cheat
sheet
and
what
I'm
going
to
do.
B
First,
actually,
what
I'm
going
to
do
before
deploying
is
register
a
delegate
so
because
this
is
a
multi-cluster
workload,
I'm
going
to
be
working
against
the
central
cluster,
but
I
want
the
central
cluster
to
be
able
to
delegate
everything
to
the
edge
cluster.
So
I
just
set
the
delegate
this
way
and
the
way
it
sets
up
the
delegate,
it
actually
uploads
the
the
cube
config
file
to
the
cluster.
B
So
I'm
deploying
again
very
similar
to
that
hello
world
that
we
did
up
here,
but
this
time,
instead
of
giving
it
the
file
direction,
I'm
giving
it
a
template,
according
to
the
template
that
I
already
registered
so
oops
I
registered
up
here
so
that
csr
file
is
already
registered
and
I'm
giving
it
an
input
here.
The
namespace
and
the
input.
Exactly
is
that
input
that
we
saw
and
tosca
up
here
so
in
task
I
define
an
input
called
namespace.
C
B
B
A
A
B
Yeah,
that's
a
great
question,
and
maybe
I'll
start
answering,
but
chris
chris
also
can
expand.
Costco
is
not
just
telco.
Tosca
has
been
used
in
talco
for
a
while.
The
interest,
of
course,
is
that
that
cloud
portability
the
ability
to
to
actually
use
a
one
tool
chain
for
for
various
clouds
that
need
to
be
supported
and
multi-vendor
approaches
are
also
very
important
and
for
telcos
they
want
to
be
able
to
work
with
different
equipment.
C
A
And
I
know
tosca's
been
around
for
quite
a
while,
because
there
was
one
logo
up
there.
That's
the
company
that
I
came
from,
which
is
active
state
so-
and
I
quite
know
them
quite
well
still
and
prior
to
that
soft
quad
and
x-metal.
So
we've
been
working
with
the
tosca
standard
for
quite
some
time.
I
think
there's
a
and
there's
a
lot
of
good
tools
out
there
that
work.
C
With
it,
by
the
way,
just
maybe
to
pick
up
on
your
question
about
telco,
I
think
one
of
the
reasons
telcos
may
have
been
a
little
bit
more
aggressive
in
adopting
tasca
than
than
enterprise
users
is
because
it
is
a
standard,
and
I
think
telcos,
for
better
or
for
worse.
The
only
way
they
can
collaborate
without
getting
into
regulatory
trouble
is
either
through
standards
or
open
source
and
tosca
gives
them
a
bit
of
both.
C
I
think
tosca
originally
obviously
was
as
a
standard
that
was
promoted
by
oasis
as
a
standard
body,
but
oasis
over
the
last
couple
years
has
also
emphasized
their
open
source
arm
and
they're
now
branding
themselves
as
the
open
standards
body,
because
they
are
conducting
all
their
standards
activity
in
an
open
way.
As
tell
said,
anybody
can
just
go
to
the
website
and
download
the
documents,
you
don't
have
to
be
a
member
to
get
access
to
the
documents.
C
You
have
to
be
a
member
to
participate
and
contribute,
but
anybody
can
get
access
to
anything,
and
on
top
of
that,
there
is
a
significant
push
towards
open
source
and
we
have
open
git
repositories
where
we
have
a
number
of
profiles
where
a
profile
is
a
type
library.
If
you
will
that
people
can
go,
look
at
as
examples
of
how
you
might
want
to
encode
domain
specific
information
using
tasker
types.
C
There
is
sample
service
templates
that
you
can
use
as
starting
points
and
start
modifying.
We
do
have
a
wiki
on
that
same
github
that
has
a
comprehensive
list
of
open
source,
as
well
as
proprietary
implementations
that
people
can
go.
Look
at
so
there's
a
lot
more
today
than
there
was
a
couple
years
ago
in
terms
of
helping
people
to
get
started
and
come
up
to
speed
more
more
quickly,
and
this
I'm
assuming
tal,
will
make
these
slides
available.
So
people
can
go.
C
B
Yeah,
I
you
know
I'll
jump
through
the.
We
have
a
lot
of
slides
here
for
the
ecosystem
and-
and
many
of
these
are
our
open
source
products
that
you
know.
If
you
want
to
launch
into
tosca
and
learn
how
to
use
it.
There's
alien
for
cloud
which
it's
actually
not
written
in
java,
it's
written
in,
go
sorry
york
is
written,
go,
and
so
there
is
kind
of
a
a
robust
orchestrator
use
this
task.
It's
already
right
now
used
by
open
telecom
cloud,
which
is
t
systems
in
europe.
B
You
can.
This
is
actually,
I
think,
launched
just
maybe
this
month
and
it's
I
think
it's
for
the
free
open
telecom
cloud.
You
can.
You
can
model
topologies
using
tosca
using
a
pretty
nice
designer,
a
graphical
designer
and
just
click
deploy
and
they'll
be
deployed
on
the
open
telecom
cloud
again.
This
is
in
the
telco
world,
but
it
it
could
be
an
interesting
way
to
see
how
tasca
can
be
used.
B
There's
of
course,
toronto,
which
I
just
showed
you,
the
for
kubernetes
other
important
products
are
cloudify
which
has
been
around
for
a
while.
It
is
not
a
pure
taska,
it
is
a
kind
of
a
tosca
inspired
dialect,
but
many
of
the
or
all
the
concepts.
Well,
not
all
many
of
the
concepts
I
showed
today
are
are
available
there
and-
and
I
think
they're
at
version
five
right
now,
so
it's
very
mature
and
it's
it's
a
great
way
to
just
download
something
and
start
to
get
used
to
it.
B
It
has
its
own
bent
you,
you
write
your
workflows
using
python
plugins,
which
are
pretty
easy
to
write.
There's,
let's
see,
I
know,
itancial
is
a
major
company
doing
stuff
in
networking.
That's
easy
to
use
onap,
which
is
the
big
telco
orchestrator
is
based
on
tosca,
but
this
is
not
easy
to
use.
This
is
not
a
download
and
run
kind
of
thing.
B
I
wrote
a
tosca
compiler
and
go
which
is
actually
being
used
by
turon
dot,
which
we
just
saw.
It
is
a
pure
task
of
compiler,
so
it
is
not
an
orchestrator.
It
just
allows
you
to
consume
tosca
and
output,
a
kind
of
graph
database
of
of
the
actual
nodes
with
all
their
information
in
them,
and
I
humbly
would
suggest
this
is
also
a
nice
way
to
start,
if
you're
not
interested
in
all
the
orchestration
stuff.
A
B
A
B
You
go
it's
it's
your
magic
touch,
diane,
so
so
yeah!
Meanwhile,
I
couldn't
show
you
the
process,
but
it
actually,
you
can
see
it
instantiated
the
main
service.
It
did
substitution
for
all
the
other
services
and
we
can
probably
see
it
right
now
on
the
dashboard
yeah.
So
we
see
all
the
workloads
are
here,
so
we
have
the
lib
libvert.
B
Where
is
it
so?
Here's
the
vert
launcher
which
comes
from
cubert
so
even
though
I'm
not
showing
it
on
openshift
today,
I'm
using
the
technologies
that
are
supported
by
openshift,
namely
kubert
and
waltus.
So
that's
very
important
here
too.
So
this
is
not
openshift
running,
but
it's
as
close
to
openshift
as
you
can
get
with
vanilla,
kubernetes
and
here
on
the
edge
cluster.
You
can
see
that
turan
dot
actually
installed
itself
on
the
edge
cluster
and
is
running
the
cnf.
A
B
B
A
A
I'd
actually
would
really
love
to
see
it
in
operatorhub.io
at
some
juncture,
even
in
in
an
alpha
or
a
beta
state,
so
that
we
can
get
more
people
doing
this
and
and
testing
and
giving
you
more
feedback.
So
it's
more
than
just
a
red,
an
anonymous
red
hat
engineer
there
on
the
slide
tiles,
not
even
taking
credit
for
his
work
here.
So
you
need
to
need
to
up
your
game
tall.
A
B
Right,
I
I
really
have
to
mention
too,
of
course,
that
chris,
my
colleague
here
is
created
his
own
orchestrator.
It
is
proprietary
software,
but
it
is.
It
is
an
example
of
of
a
totally
different
approach
than
I
took
in
turon
dot
for
orchestration
and
term
dot.
I
created
something
for
kubernetes,
it's
a
kubernetes
operator.
It
works
with
kubernetes
paradigms.
B
It
is
a
kubernetes
orchestrator
right,
a
replacement
for
helm.
What
chris
created
is
you
could
call
it
a
general
purpose.
Tosca
orchestrator,
so
ubicity
does
not
target
any
specific
cloud
platform.
Rather
it
would
let
you
create
profiles
that
you
can
work
with
any
cloud
platform
using
any
technology,
so
it's
kind
of
a
one-stop
shop
for
for
any
platform
that
you
have
and
chris
I
don't
know
if
you
want
to
talk
more
about
that,
a
different
approach.
C
Yeah,
I
think
the
main
point
here
is
that
it
illustrates,
I
think
the
power
of
the
tasker
language,
tasker
really
isn't,
doesn't
prescribe
any
specific
orchestration
paradigm.
It
really
is
a
language
to
to
model
services
that
you
can
deploy
or
applications
that
you
can
deploy
in
a
general
purpose
fashion,
and
then
it
allows
you
to
introduce
additional
information
about
those
services
that
are
specific
to
whatever
orchestration
approach
you're
using
and
so
what
what
tal
showed
is
at
one
end
of
the
spectrum,
which
is
very
focused,
very
specific
for
kubernetes.
C
What
I've
built
with
ubicity
is
sort
of
the
other
end
of
the
spectrum
spectrum,
which
is
as
general
purposes
as
general
purpose
as
possible
and
there's
things
in
between
you
can
do
as
well,
so
that
shows
you
the
power
of
the
language,
but
at
the
same
time
I
think
that
can
also
make
tosca
look
a
little
a
little
challenging.
I
think,
picking
up
on
some
of
the
questions
related
to
well.
How
easy
is
it
to
get
started?
It
may
be
a
little
daunting
based
on
the
examples
that
pal
showed.
C
That
may
give
people
the
impression.
Oh
my
god
do.
I
have
to
specify
all
these
things
just
to
get
a
simple
hello
world
program
started,
but
I
think
one
of
the
things
that
you
should
keep
in
mind
is
that
you
can
use
as
much
and
as
little
of
the
tasker
language
as
you
as
you'd,
like,
depending
on
the
sophistication
of
the
of
the
of
the
orchestration
paradigm,
you'd
like
to
like
to
use
and
sort
of
in
the
simplest
form
all
tusca
does.
C
Is
it
models,
applications
and
services
as
a
topology
and
has
a
topology
of
nodes
and
relationships
between
those
nodes?
And
that's
it
I
mean
that's
that's
about
as
generic
as
you
can
get
in
terms
of
modeling
application
or
or
service
topologies,
and
then
we
do
that
using
templates,
but
not
data
templating.
C
If
your
task
orchestrator
has
knowledge
about
a
specific
type
for
your
application
domain,
like
kubernetes
types,
then
you're
building
a
domain
specific
orchestrator,
but
all
of
that
is
possible
using
task
of
the
language
and
that's
where
a
lot
of
the
flexibility
and
a
lot
of
the
power
comes
comes
into
play
and
you
can
from
there
you
can
use
composition,
features
you
can
use
decomposition
features.
I
think
that
was
a
question
about
well
is
there's
a
language
that
that
just
ultimately
calls
scripts.
C
No,
I
think,
depending
as
tell
showed
you
can
have
orchestration
done
as
a
kubernetes
or
operator.
So
clearly
it
doesn't
just
call
scripts,
but
for
configuring
some
of
your
containers,
you
may
need
a
script
to
do
some
additional
configuration
and
you
can
define
that
all
in
one
place
and
package
all
together.
A
B
I
I
would
say
absolutely-
and
you
know
emphasize
or
maybe
underscore
a
point-
we've
been
making-
you
don't
have
to
pick
one
orchestrator
or
the
other.
You
can
use
the
right
tool
for
the
right
domain.
The
value
proposition
of
tosca
is
not
centralization.
It's
not
saying
put
all
your
eggs
in
this
specific
product.
The
value
proposition.
As
I
understand
it
is
you
can
have
a
common
tool
chain.
So
there
might
be
differences
right.
B
If
you
think
about
compilers
you're
compiling
code,
you
might
compile
code
to
different
platforms
with
different
build
machines,
but
you're
writing
c
code
everywhere,
you're
using
auto
tools,
say
everywhere
or
cmake.
You
have
a
tool
chain
that
you
can
depend
on.
That
has,
of
course,
support
for
different
platforms
eventually,
but
you're
always
working
in
the
same
paradigm.
You
don't
have
to
do
something
completely
different.
B
B
So
you
can
say
okay!
Well,
why
do
I
need
a
single
language
for
all
of
these
different
domains?
So
many
advantages.
Think
of
something
like
the
eclipse
winery
project
that
lets
you
graphically
design
all
of
these
drag
and
drop
node
types
and
connect
them
with
lines
with
the
relationships
that
you
need.
B
If
you
have
something
that
consumes
task
and
implements
it,
that's
what
you
can
be
focused
on.
You
don't
have
to
be
concerned
about
all
the
very
complicated
work
that
goes
into
modeling,
for
example,
what
kubernetes
does
right
now
with
custom
resource
definitions,
it's
kind
of
inventing
its
own
wheels
it.
You
know
it
uses
the
open
api
schema
format,
but
it
has
to
kind
of
build
it
from
scratch,
something
that
would
be
workable
within
kubernetes.
B
B
A
A
B
B
You
know
you
see
it
even
in
ansible,
playbooks
right,
there's
a
series
of
tasks
that
you
run
and
those
individual
tasks
might
be
some
custom
bash
script
right,
but
the
orchestrator
job
in
that
case,
in
the
kind
of
the
legacy
lifecycle
management,
was
to
bring
these
bash
scripts
together
in
in
some
way
that
is
a
more
manageable
workflow
right.
So
you
can
look
at
failures.
You
can
run
things
in
parallel,
etc.
B
Now
I
think
kubernetes
totally
throws
that
out
the
window
with
the
new
with
its
own
cloud
native
paradigm,
for
orchestration
right,
you
schedule
resources
rather
than
provision
them
right.
It's
it's
it's
intent
based.
So
I
would
think
that
in
when
you
work
in
kubernetes
you're,
usually
not
going
to
be
running
scripts
you're
going
to
expect
components
to
cloud
natively
configure
themselves
orchestrate
themselves.
B
What
I
showed
here
was
a
demo
of
how
you
can
do
it
and
by
the
way
it
does
use
kubernetes
native
paradigm
running
the
script
uses
kubernetes
api
servers,
spdy
connector
for
containers.
So
it's
actually
it's
not
doing
an
ssh
into
the
container,
which
you
can't
do.
Of
course
it's
actually
using
the.
I
think
it's
a
socket
based
connectivity
into
those
containers.
B
B
C
C
C
So
that's
a
major
feature
evolution.
If
you
will
from
where
the
1.0
and
the
1.x
specifications
were
in
the
process,
the
spec
has
been
cleaned
up
tremendously.
I
think
early
versions
of
the
spec
had
some
gaps
that
people
filled
in
based
on
their
own
preconceived
notions
and
experiences
and
as
a
result,
as
a
result
of
maybe
some
diversions
in
interpretation
of
what
things
mean.
C
The
version
2.0
spec
cleans
all
that
up
and
will,
as
a
result,
be,
will
result
in
just
more
consistent
and
more
correct
implementations
and
there's
a
variety
of
things
that
we
can
go
into
at
some
other
time.
But
but
that's
a
major
step
forward.
We'd
love
additional
participation.
If
people
are
interested
in
helping
out
both
on
the
open
source
site
with
either
puccini
or
turin.org
on
the
standardization
site,
helping
to
to
contribute
to
the
language
specification
itself,
they
can
contact
us
and
we'll
have
those
conversations.
A
Well,
that's
a
really
good
place
to
pause
for
today
and
we'll
definitely
see
if
we
can
connect
the
dots
with
with
tall
and
you
and
some
of
the
sigs
in
cncf
and
kubernetes.
I
think
tom
mentioned
a
couple
of
times
that
you
know
you,
I
think
you're
participating
in
them,
but
I
also
would
love
to
see
a
little
more
movement
on
the
turin
dot
operator
and
getting
down
greater
hub.io.
So,
let's
see
if
we
can't
make
that
happen
and
have
you
guys
back
again
soon
and
find
some
more
collaborators
for
tall.
A
So,
if
you're
out
there
listening
and
watching
this,
we'll
put
all
the
links
in
the
youtube,
video
and
upload
that
shortly
hopefully,
that'll
kick
off
and
spur
some
conversations
and
we'll
definitely
keep
tabs
on
this
conversation.
So
I
want
to
really
thank
you
both
for
joining
me
today.
I
had
a
few
walks
down
memory
lane
and.