►
From YouTube: CDF SIG Interoperability Meeting 2020-02-20
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
A
A
A
A
A
A
A
A
Mix
being
recorded,
okay,
good,
because
we
want
to
record
these
meetings,
not
just
for
our
agenda,
but
also
we
will
have
the
presentations
from
projects
and
users,
it's
good
to
have
them
uploaded
YouTube,
so
people
can
watch
them
offline.
So,
let's
start
the
agenda
is
available
on
Google
Doc.
As
you
know,
and
topics
for
today.
Our
first
topic
is
the
co-chairs,
for
the
sake
followed
by
common
walk
of
life,
time
image,
which
we
start
working
three
weeks
ago
and
then
a
new
topic.
A
We
discussed
in
previous
meeting
to
start
to
work
on
sick
goals
and
roadmap,
and
then
the
next
topic
would
be
the
discussion
and
a
standardization
of
content
based
step.
Execution
and
Jason
is
with
us
introduce
topic
to
us
and
we
will
have
the
Tecton
presentation
followed
by
discussion
on
Christy,
and
if
you
have
any
topics
you
would
like
to
have
discussed,
please
add
it
to
the
admin
part.
So
we
touch
those
topics
before
we
move
to
presentation,
and
then
we
use
the
rest
of
the
meeting
for
the
Tecton
presentation
and
discussion.
A
So
the
first
topic
is
the
co-chairs.
I
think
the
topic
came
up
during
the
very
first
meeting
and
the
question
was
like:
should
the
adapt
co-chair
set
up
similar
to
other
CDF
six
common
practice,
the
six
have
multiple
cultures
and
the
agreement
was
to
have
multiple
co-chairs.
So
we
had
a
nomination
period
which
ended
on
10th
of
February,
and
we
had
two
people
nominates
by
others
as
Christian
and
the
other
one
from
walk.
A
Well
Watson,
so
Christie
accepted
nomination,
but
I
own
heard
from
Watson.
Yet,
even
though
I
sent
him
an
email
explicit
pointing
the
nominations
for
he
didn't
come
back
I
suppose
we
will
have
two
co-chairs
for
the
sake,
because
no
one
else
also
nominated
himself
or
herself.
So
we
go
ahead
with
two
coaches
and
congratulations
Christie
for
being
coach
F
and
welcome
to
the
club.
A
A
Meeting
minutes
and
I
think
we
have
pretty
extensive
time
network
of
David
there,
but
we
lack
reviews
like
yes,
we
put
some
information
about
the
tools
and
technologies
used
by
many
into
the
dog
and
we
edit
the
terms
used
by
the
tools
and
it,
and
we
also
have
some
mapping
for
the
terms
across
different
tools.
But
since
I
don't
know
all
these
tools,
I
might
have
made
mistakes
or
I
might
have
missed
some,
such
as
Argo
Emily
pointed
out.
It
is
very
important
if
we
can.
A
You
know,
review
this
document
and
finish
the
work
with
this,
so
we
can
contribute
this
to
domain
and
others
can
come
and
take
a
look
at
the
document
and
get
some
kind
of
idea.
What
each
term
means
in
different
tools
and
so
on
so
I
urge
everyone
to
go
and
use
the
content
send
comments.
So
we
finish
this
work
of
a
student
about
a
month
now
I
think
at
least
few
weeks,
and
we
better
remove
on
this
specific,
close
this
topic.
So
anyone
wants
to
talk
about
this
topic.
Any
comment
hi.
D
This
is
Tracy
I
think
it's
looking
really
good
and
I'd
almost
encourage
us
to
to
never
sort
of
see
it
as
a
finished
document,
but
maybe
even
just
merge
it
in
now
and
kind
of
keep
encouraging
people
to
sort
of
keep
improving
it
and
going
back
to
it.
I
know:
I
did
plan
to
kind
of
do
more
of
a
review
so
and
I
still
plan
to
do
that,
but
I
think
in
in
the
sense
of
kind
of
you
know
minimum
viable
page.
It's
it's
in
pretty
good
shape.
A
B
A
D
A
The
third
topic
is
about
starting
to
work
on
the
course
and
roadmap,
so
this
topic
was
brought
up
by
I.
Think
Tracy.
You
brought
up
this
topic,
among
others,
and
one
of
the
ideas
was
to
look
at
what
the
name
elopes
SiC
is
doing
and
used
that
as
an
example,
so
based
on
that
feedback,
I
created
an
issue
on
the
cylinder
phase
in
triple
I.
Just
put
what
we
discussed
during
previous
meeting
and
what
we
are
working
right
now
is
to
start
this
work.
A
So
we
are
both
working
to
have
some
contributors
in
this,
and
if
anyone
wants
to
start
this
or
just
send
a
PR,
I
may
start
working
on
together,
because
it
is
important
if,
if
you
can
identify
our
goals
and
what
are
we
trying
to
and
come
up
with
some
basic
roadmap
that
could
help
us
to
start
very
a
more
structured
way
and
target
certain
areas
to
work
with
so
I,
not
asking
anyone
to
sign
up
for
this
right
now.
Yeah
do.
E
We
have
any,
are
there
any
like
initial
thoughts,
or
is
anyone
written
up?
Any
sort
of
like
I,
think
I
think
that
something
like
this
would
be
much
easier
to
contribute
to
if
there
was
kind
of
like
a
started,
a
place
to
start
from
and
I'm
wondering
like
what
people
are
viewing
as
what
they
would
want.
This
cig
to
do
in
that,
like
I,
feel
like
there's
like
a
couple
different
ways,
they
could
go
like
one
way
it
could
go.
E
On
the
other
end,
it
could
be
that
maybe
this
SIG's
job
is
just
keeping
track
of
like
terminology,
that's
in
the
industry
and
like
kind
of
providing
a
reference
for
that
kind
of
thing
and
like
sort
of
reporting
on
the
state
of
interoperability,
I
wondering
what
other
folks
think
they
would
want
to
see
from
from
the
stake,
or
it
may
be
that
maybe
somebody
has
done
this
work
already.
It
has
a
starting
point:
I.
D
Think
Chrissie,
when
we
had
the
very
first
meeting
a
whole
bunch
of
folks
sort
of
shared
how
they
would
see
it,
and
it
was
like
the
things
you
mentioned,
and
more
and
I
don't
know
about
everybody
else.
I
want
to
do
all
of
them
so,
including
you
know,
just
kind
of
promoting
the
ways.
Different
tools
do
interoperate
and
raising
visibility
in
the
need
for
this
and
I.
Think
that's
why
maybe
kind
of
a
road
map
is
important
because
we're
not
going
to
get
round
to
everything.
So
it's
almost
like.
How
do
we
face
it?
D
E
Think
I
like
what
you
just
mentioned,
it
could
be
interesting
to
start
with,
like
you
were
mentioning
like
kind
of
showing
ways
that
maybe
existing
tools
already
interoperate
would
be
like,
because
you
could
kind
of
highlight
that,
as
sort
of
like
a
positive
thing,
we
want
to
see
more
of
and
then
also
sort
of,
maybe
making
it
clear
like
one
thing
that
I'm
thinking
is
that
maybe
for
some
folks,
it's
not
even
clear
why
this
is
important,
but
like
highlighting
some
of
the
challenges
around
it.
Maybe
those
could
be
some
like
initial
goals.
D
Yeah
I'll
have
a
stab
at
maybe
putting
together
kind
of
my
initial
thinking
on
the
roadmap
on
kind
of
what
are
the
different
categories.
What
are
the
way
we
progress
them
and
that
that
would
be
one
and
I'll
send
that
round
and
just
in
the
in
the
kind
of
roadmap
like
one
of
the
things
I
know
they
do
in
ml,
ops,
which
I
want
to
go
slightly
differently.
So
I'm
going
to
encourage
us
to
do
in
this
group
is
rather
than
kind
of
laying
out
years.
D
You
know
we're
going
to
do
this
in
year,
1
year,
2,
since
we
you
know,
you
can't
necessarily
predict
the
timescales.
Just
take
a
more
of
a
now
next
later
approach,
where
the
things
we're
doing
now,
we
have
lots
of
granularity,
we
know
the
specifics
and
then
we
can
get
people
to
work
on
them
and
then
things
for
next
and
later
the
further
on
you
go
the
more
there
are
sort
of
big
ideas,
but
we
have.
We
would
scope
them
till
we
sort
of
deal
with
the
things
and
now
that
sounds
great.
A
Yeah
thanks
for
this
Tracy,
actually,
the
thing
you
mentioned
there,
the
initial
categories
and
the
way
to
deal
with
them
even
right.
Now
we
have
some
ideas
about
what
are
the
things
people
think
when
they
start
talking
about
interplay
with,
for
example,
when
we
proposed
the
cig
first
time,
I
think
it
was
Tong
from
the
mini
networks,
inter
ability
for
him
was
having
some
kind
of
pipeline
language,
so
he
can
move
the
jobs
or
patterns
across
different
tools
in
Erickson's
case,
as
they
present
during
the
previous
meeting.
A
It's
different
way
of
looking
into
interoperability,
so
we
already
have
some
I
think
three,
four
different
use
cases,
interpolate
area
and
as
you
suggested,
if
we
can
somehow
list
those
areas
and
maybe
come
up
with
some,
you
know
focus
areas
or
whatever
it's
called
to
call
people
to
contribute
those
areas.
If
some
people
want
to
work
on
pipeline
language,
they
can
create
a
small
task
force
or
whatever
we
name
it,
and
those
people
can
start
working
with
it,
come
up
with
some
ideas,
so
we
can
make
those
topics
more
visible.
A
Astray
said,
please
keep
an
eye
on
the
repository
and
many
where
you
see
to
request
that.
Please
just
jump
in
and
quiet
your
comments
there,
so
we
get
this
started
as
well.
So
this
is
the
roadmap
topic,
and
you
know
next
topic
is
actually
related
to
the
roadmap
topic,
because
what
Jason
brought
up
the
standardization
of
container-based
step
execution
is
yet
another
interval
T
topic,
at
least
that's
what
I
think
personally,
because
when
you
look
at
github
or
circle
CI
or
detect
on,
they
all
have
some
kind
of
steps
or
in
circle
CI.
A
It's
called
orbs
and
they
use
steps
to
execute
some
commands
and
when
Jason
reached
out
about
this
topic,
I
was
like.
This
is
great,
because
I
know
thought
of
this
as
something
we
can
work
and
start
getting.
People
realize
this
is
an
important
thing,
so
I
just
stopped
talking
and
test
Jason,
and
the
document
is
a
really
long.
B
How's
it
goin
thanks
everybody
for
having
me
here,
maybe
open
up
the
introduction
document
and
another
tab,
and
we
can
just
have
that
up
while
I'm
talking.
But
the
basic
idea
here
is
that
we've
all
got
something.
That's
like
I
thought,
the
terminology
thing
so
probably
I'm
stepping
on
all
kinds
of
different
terminology
here,
but
like
some
kind
of
step
executor
where
we've
got
a
single
task.
That
needs
to
be
done
as
part
of
a
pipeline,
so
this
is
probably
smaller
than
what
you
might
consider
a
job.
B
But
what
the
way
this
is
being
implemented
in
orbs
and
in
actions
and
I
understand.
There's
something
similar
in
touched
on
is
that
everyone
is
writing,
basically,
a
container
a
way
to
pass
parameters
at
runtime
to
that
container
and
then
get
the
output
back
in
an
own
format
that
can
then
be
handled
by
the
CI
CD
system.
B
And
then
you
can
assemble
these
into
your
different
things
so
like
if
you
look
at
all
of
the
individual
actions
or
individual
orbs,
this
is
kind
of
what
I'm
talking
and
then
so
here,
I
get
that
we
were
just
about
to
build
our
own
another.
Slightly
different
version,
incompatible
version
of
the
same
thing
and
I
thought
it
might
be
nice
to
bring
here
and
see
if
there's
any
interest
in
maybe
coming
up
with
a
simple
standard
that
we
could
all
be
compatible
with
yeah
I
guess
I
will
I
will
pause
there.
If
there's
any
questions.
E
One
thing
that
I'm
curious
about
is
I:
guess
what
tech
time
we've
kind
of
gone
back
and
forth
around
standardizing
on
the
I
guess
what
you're
calling
a
step
here
or
starting
what
you're
calling
it
actually
wait?
What
is
the
name
that
we're
using
here
containerized
script,
I
guess,
which
seems
to
kind
of
map
to
a
step,
wait
hold
on
I'm
gonna,
look
at
the
terminology.
Docs
I
can
get
this
straight.
So
not
ok,
so
this
is
in
the
context
of
get
it
lab
right.
B
E
B
A
script
section
which
contains
like
individual
lines
that
are
run
those
can
be
bash
script,
so
they
could
also
be
an
invocation
of
a
container
to
do
something,
that's
wrapped.
So
this
is
that
wrapping
wrapping,
some
kind
of
set
of
commands,
or
fortunately,
inside
of
a
container
that
can
then
be
essentially
called
from
the
command
line.
Okay,.
E
B
E
E
D
E
E
That's
I
think
in
in
Tecton
we
decided
for
better
or
worse
and
I.
Don't
think
we're
like
a
hundred
percent
happy
with
this
decision,
but
at
the
moment
we
use
the
kubernetes
container.
Spec
is
like
the
way
that
we
express
that
which
has.
It
has
some
benefits
in
that
it
has
things
like
environment
variables
and
like
like
arguments,
but
then
it
has
like
weird
kubernetes
specific
stuff
in
there
as
well,
for
better
or
worse,
like
well,
I
mean
it
could
be
okay,
but,
like
volume
mounts
are
in
there
exactly.
B
Yeah
and
so
yeah,
this
is
exactly
what
what
I'm
talking
about
we're
on
the
same
page
and
I
do
think
it
might
be.
It
might
be
nice
yeah.
Well,
it
would
really
be
nice
if,
for
example,
you
could
run
any
any
action
that
anybody
wrote
or
that
there
would
be
a
common
ecosystem
of
developers
producing
these
little
snippets
or
whatever
you
want
to
call
them
containers
that
can
do.
You
know
simple
single
things
that
can
then
be
wired
together
and
they
were
dated
or
operated
with
each
and
there
was
not
like
well.
B
E
Think
the
one
thing
that's
hard
for
me
to
totally
wrap
my
head
around
is
just
what
the
difference
would
be
between
like,
because
I
feel
like
the
underlying
thing.
Inside
of
one
of
these
is
the
image
and
like
the
image,
will
it'll
invoke
a
binary
that
takes
some
arguments
and
like
it
expects
some
environment
variables
and
maybe
expect
some
files,
but
then
like
that?
That
feels
to
me,
like
it's
part
of
the
image
interface
itself.
So
then
I
guess
I.
B
C
Can
I
chime
in
here
it
seems
like
we
really
are
just
groping
around
terminology
here,
standardization
I
feel
standardizing
around
having
a
shell
script.
Type
of
interface
to
an
image
is
pretty
darn
standard
and
I.
Frankly,
I
wouldn't
want
us
to
make
it
any
more
complex
than
that.
So
what
what
is
it
on
the
I
guess
I'll
go
back
to
the
the
the
standardized
it
you
know,
standardizing
containerized
script,
execution
document.
C
C
The
mechanism
of
running
that
script
is
the
age-old
tried-and-true
call,
you
know,
have
an
image
and
you
call
its
initial
script
with
just
bash
script
or
whatever
that
you
put
into
the
image,
and
that
leaves
the
door
open
for
anyone
to
to
create
whatever
that
image.
The
capability
of
that
image
is
able
to
do
you
pass
it
in
in
that
string,
and
it
just
does
it
and
I
I
struggle
to
think
that
there's
any
more
standardization
required
than
that.
B
C
But
you
understand
what
I'm
saying
with
the
how
universal
it
is
to
have
a
image
simply
just
what?
Whatever
your
image
is,
the
string
you
pass
in
as
its
command
that
totally
leaves
it
open.
You
can
possibilities
are
endless
at
that
point
and
that's
what
you
really
want
with
a
common
execution
engine
across
various
different
languages
and
stacks
and
what-have-you.
C
I,
don't
doubt
that
we
have
I
mean
at
eBay.
We
have
our
own.
We
actually
put
together
our
own
execution
as
continuing
continuous
delivery
execution
engine
and,
yes,
it
does
similar
kinds
of
things
to
tacked
on.
But
of
course
it
doesn't
it's
not
standardized,
and
once
we
saw
Tecton
and
how
it's
doing
it,
I
can't
imagine
in
anything
at
least
I
can't
imagine
anything
else.
That
is,
that
is
even
more
generalized.
B
E
Yeah
I,
don't
know
it's.
It
is
like
I
feel
like
there's
like
levels
of
standardization
or
like
the
bottom.
One
is
going
to
be
the
image
and
then
there's
like
kind
of
like
things
you
can
put
on
top
of
that,
which
pretend
potentially
is
something
that's
right
above
the
image
and
then
there's
something
that
like
puts
multiple
images
together
and
then
there's
something
that
puts
like
multiples
of
those
together
and
you
kind
of
like
complex
things.
From
that.
C
So
Christi
we
I
mean
in
tacked
on.
We
definitely
are
missing
the
actions
piece,
so
I've
I
haven't
used
github
actions,
but
I've
read
into
them,
and
this
is
something
that
and
Andrea
Fratelli
started
with
the
event
mechanism
for
his
event,
like
it's
a
proposal
and
that's
still
ongoing,
and
that
is
something
that's
definitely
needed.
E
D
B
Main
benefit,
I
think,
is
that
just
a
minute
like
there's
a
lot
of
contributors
to
actions
or
orbs,
and
if
somebody
writes
a
really
nice
action
that
would
benefit
a
ton
of
people
and
open
sources.
It
then
you
would
have
to
have
somebody
today
like
translated
and
make
different
versions
for
all
of
the
different
CI
CD
systems
in
order
and
all
you
would
be
doing-
is
kind
of
wrapping
it
in
syntax
changes,
so
I
think
yeah.
That's
essentially
that
the
core
of
might
be
a
good
idea
here.
A
So
I
think
one
think
many
of
you
brought
up
is
to
look
at
what
kidnap
actions
and
circles
here.
Orbs
are
doing
and
I
actually
try
to
reach
out
to
Circle
CI
person,
I
think
Tracy.
You
are
in
the
mail
as
well
and
we
didn't
get
any
response
from
him
and
also
we
are
looking
for
someone
from
github
to
invite
them
to
this
meeting
and
ask
them
how
they
are
doing
this
similar
things
in
github
action
and
service
hi
orbs.
A
So
if
you
know
anyone
from
github
or
circus
yeah
just
get
us
in
touch
with
that
person,
and
we
can
invite
the
person
to
this
meeting
and
have
further
conversations
on
this
topic
because,
like
what
technology
is
doing
and
what
Raman
mentioned
is
kind
of
standard
enough.
But
since
we
don't
know
github
and
circus
high
specific
things,
it
would
still
make
sense
to
keep
this
topic
in
the
agenda
and
have
yet
another
conversation
around
this
topic
to
see.
A
B
C
The
way
I
just
posted
in
the
chat
for
our
zoom
meeting
here,
the
Tecton
actions
proposal,
which
Andrea
Andrea
Fratellis
started,
and
if
you
see
my
he
and
I,
went
back
back
and
forth
on
some
comments.
It's
exact.
We
are
definitely
missing
this
functionality
in
in
Tecton,
and
what
I
didn't
want
to
do
was
to
recreate
the
wheel.
C
There's
I'd
like
to
build
on
the
lessons
learned
from
previous
systems
who
have
tried
this
and
github
actions
is
actually
a
very,
very
nice
interface
to
look
at,
and
if
you
know
that
one
of
the
purposes
of
Tecton
is
to
standardize
CI
CD
across
the
board
across
the
industry.
This
is
what
I
understand
it
and
Christy
can
correct
me
on
this.
If
that's
not
the
case.
E
A
C
E
E
A
A
B
A
Great
I
think
this
was
good
at
this
week.
Understand
Tecton
has
something
here,
and
that
seems
to
be
something
to
look
at
and
perhaps
towards
with
others
to
see.
If
that
it
makes
sense
to
some
kind
of
stand
out
there.
So
the
I
don't
see
any
new
topic
editor.
So
before
we
started
taking
presentation,
anyone
has
any
new
topic
to
wind
up
hi.
D
This
is
Tracy
I'm,
just
gonna
do
a
short
announcement
that
if
anybody
is
going
to
be
at
cube,
con
Amsterdam
I
know
there's
a
few
folks
who
will
be
there
and
we
started
throwing
around
the
idea
of
getting
together
to
discuss
sort
of
like
common
metadata.
Around
deployments
like
how
do
you
define
a
deployment
and
how
do
you
standardize
that
so
it's
sort
of
very
early
days,
but
like
the
folks
who
write
flagger
and
the
Jenkins
X
folks
were
notionally
gonna
find
some
time
to
get
in
a
room
and
just
thrash
some
things
around?
D
A
E
A
A
E
So
all
right,
so,
first
of
all,
I'm
going
to
share
with
you
Tecton
mission.
So
this
is
what
Tecton
is
trying
to
do.
So
Tecton
is
trying
to
be
the
industry-standard
cloud
native
CI,
CD
platform,
components
and
ecosystem,
so
web
platform,
components
in
that
Tecton
is
trying
to
be
building
blocks,
that
you
use
to
build
CI,
CD
systems
and
then
ecosystem
in
that
the
idea
is
that
we
want
to
if
we
can
kind
of
I
guess
what
this
group
is
about
to
an
extent.
E
If
we
can
standardize
on
some
of
these
things,
then
we
can
easily
build
up
an
ecosystem
of
tools
around
them.
So
you
don't
have
to
make
something
that
interacts
with
this
system
and
that
system
and
that
system.
You
can
just
make
something
that
interacts
with
these
building
blocks
and
then
it
will
work
with
many
systems,
or
at
least
that's
that's
the
vision
and
first,
and
you
probably
notice
that
cloud
native
is
in
that
definition,
so
I
will
define
what
cloud
native
means
in
this
context
so
on.
E
The
left
here
is
a
very
brief
summary
of
the
CNCs
definition
of
cloud
native,
which
is
micro
services
in
containers
which
are
dynamically
orchestrated
to
optimize
resource
utilization
and
then
on.
The
right
is
what
this
kind
of
ends
up.
Looking
like
for
a
lot
of
folks
so
for
a
lot
of
people,
cloud
native
means
that
the
core
building
block
of
what
you're
making
is
images
or
containers
and
that
you're
somehow
orchestrating
those
containers
and
often
that
the
mechanism
for
that
is
kubernetes,
but
it
isn't
always
in
in
the
case
of
Tecton.
E
It
is
images
and
containers
which
are
orchestrated
with
they
are
orchestrated
with
kubernetes.
But
it's
interesting
that
the
API
and
that
we're
trying
to
standardize
on
is
the
more
important
part
and
kubernetes
is
kind
of
we're
trying
to
treat
it
more
as
an
implementation
details.
So,
theoretically,
you
could
use
the
same
API
with
something
that's
not
kubernetes,
underneath
and
also
this
is
referring
to
the
the
CI
CD
execution
platform.
Not
to
like
you
could
be
deploying
to
something.
That's
not
cloud
native.
You
could
be
building
something.
E
That's
like
an
an
iOS
app
or
something
like
that.
But
it's
talking
about
the
execution
of
the
CI
CD
system
itself
and
the
next
question
that
people
usually
ask
is
who
this
is
for
I,
don't
know
whether
it's
who
or
whom
so
I
tried
to
go
with
both.
If
you
have
heard
this
phrase,
you
might
furthest
phrase
before
I
always
surprised
how
many
people
have
not
heard
it.
E
I
thought
it
was
like
a
totally
normal
phrase,
but
apparently
it's
not,
but
this
is
I
think
this
is
an
interesting
way
to
look
at
Tecton
idea
of
the
porcelain
versus
the
plumbing.
So
if
you
look
at
like
a
toilet,
there's
there
different
parts
to
it,
but
one
part
is
kind
of
the
user
interface
or
like
the
porcelain
part,
and
then
underneath
there's
the
plumbing
that
actually
makes
it
work.
E
E
Oh
and
now
toilet,
oh
geez,
yes,
it's
my
toilet,
so
I
need
some
toilet
humor
in
here,
but
anyways.
If
you
just
encountered
the
plumbing,
you
wouldn't
actually
be
able
to
use
it.
You
need
both
of
them,
so
Tecton
is
trying
to
be
the
plumbing.
It
is
not
just
not
trying
to
be
the
porcelain,
which
means
that
for
many
end,
users
Tecton
would
not
be
the
thing
that
they
would
want
to
use.
They
probably
do
not
want
to
construct
their
entire
CIA.
They
really
don't
want
to
construct
their
entire
CIC
system.
E
They
probably
want
to
use
something
that
somebody
else
has
built.
So
Tecton
is
trying
to
be
trying
to
be
the
building
blocks
that
someone
else
will
build
the
porcelain
on
top
of
to
create
a
great
user
experience.
But
that
being
said,
we
do
have
kind
of
two
sorts.
Two
categories
of
people
that
we're
targeting
on
the
one
side
are
people
who
are
building
CI
CD
systems,
which
we've
kind
of
talked
about
already,
and
they
would
get
a
bunch
of
benefits
from
building
on
top
of
Tecton.
E
So
the
idea
would
be
that,
if
you're
building
a
CI
CD
system,
you
get
a
lot
of
value
from
just
using
these
Tecton
building
blocks,
and
then,
additionally,
if
you
make
it
so
that
our
catalog
of
reusable
components
works
with
your
system,
then
users
get
the
benefit
of
being
able
to
use
this
catalog.
They
can
potentially
build
really
complicated
pipelines
really
easily.
They
could
take
those
pipelines,
move
them
to
completely
different
systems.
They
don't
have
to
worry
about
lock-in,
and
then
they
can
get
like
a
rich
ecosystem
of
tools
that
work
with
them
yeah.
E
So
those
are
the
goals
and
then
I'm
going
to
go
over
very
briefly
what
the
what
the
components
are
inside
of
Tecton
and
then
I'll
go
through
this
fairly
quickly
and
then
I'll
open
up
for
questions,
and
we
can
go
back
to
any
slides
if
things
weren't
cleared
so
kind
of.
Like
we
were
talking
about
already
images
are
kind
of
an
existing
standard
that
everybody
has
kind
of
rallied
around
so
they're
at
the
very,
very
most
basic
building
block
for
Tecton.
E
The
next
building
block,
on
top
of
that
is
something
that
we
call
a
step
which
is
actually
almost
one-to-one
with
a
kubernetes
container
spec,
and
this
adds
thing.
It's
like
environment
variables
and
arguments
and
then
some
other
kubernetes
things
that
we
don't
want,
but
mostly
this
is
just
so
you
can
explain
how
to
invoke
an
image.
E
We
call
that
workspaces
and
then
you
can
express
the
task
will
produce
some
kind
of
results
like,
for
example,
the
digest
of
the
image
that
it
built
if
you're,
building
and
publishing
an
image,
and
then
the
next
type
that
we
add
on
top
of
that
is
a
pipeline
which
lets
you
put
tasks
together
into
a
graph
you
can
take.
You
can
take
inputs
and
outputs
and
pass
them
between
the
tasks
in
the
form
of.
If
a
task
produces
a
result,
you
can
pass
that
as
a
parameter
to
another
task.
E
You
can
also
have
if
a
task
is
using
a
workspace,
you
can
take
that
workspace
and
use
it
in
another
task.
For
example,
if
you
wrote
some
files
that
need
to
be
consumed
by
another
task
and
then
we're
adding,
in
other
things,
that
people
need
like
being
able
to
express
conditions
like
only
execute
this,
if
it's
running
against
mastered
or
things
to
do
on
failure
like
if
this
whole
thing
fails,
you
should
you
should
update
the
pull
request
or
you
should
send
a
message
to
slack
that
kind
of
thing,
so
this
is
probably
I'm
guessing.
E
This
is
probably
the
part.
That's
most
interesting
to
this
group,
so
this
part
is
just
super
fast
there's
another
related
project
called
Tecton
triggers,
which
is
all
about
event,
triggering
I'm
not
going
to
describe
what
these
components
are,
unless
somebody
asks
afterwards
I'm
just
going
to
assume
that
we're
more
interested
in
those
other
components.
E
But
this
this
is
another
potential
place
where
we
could
have
some
sharing
of
components,
but
I
think
it's
a
bit
less,
where
it's
a
bit
less
clear,
and
this
project
is
also
much
newer
and
then
finally,
I
want
to
talk
about
the
catalog,
which
is
the
the
place
that
we
are
hoping
to
basically
have
all
these
reusable
components.
So
this
is
just
a
very
brief
overview
of
the
catalog
on
the
left
is
kind
of
a
list
of
sort
of
all
of
the
components
that
we
might
want
to
be
sharing
in
the
catalog.
E
Interestingly,
as
we
talked
about
before
steps
are
not
on
this
list,
we
assume
that
we'd
want
to
share
images,
tasks,
definitions
and
then
it
kind
of
gets
fuzzier
from
there.
It's
not
clear
how
useful
it
is
to
share
entire
pipelines,
but
maybe
people
would
want
to
have
out-of-the-box
pipelines
that,
like
do
a
tech
like
a
lint
test,
push
deploy
or
something
like
that,
it's
possible
and
then
on.
E
The
right
are
kind
of
our
very
rough
plans
around
the
catalog,
which
are
to
kind
of
try
to
take
best
practices
from
helm,
charts
and
have
sort
of
like
a
sandbox
level
of
catalog
components
in
an
official
level.
It's
really
important
that
all
of
the
components
that
are
in
there
be
really
well
tested
and
they
be
really
well
documented.
E
If
you
look
at
the
catalog
today,
you
will
not
see
all
of
this,
so
it's
work
that
we
need
to
do,
but
it's
also
very
important
that
you'd
be
able
to
version
these
tasks,
so
you
can
make
changes
to
them
without
breaking
people
and
that
you'd
be
able
to
if
that
last
part
is
probably
too
specific
to
technically
get
into,
but
yeah,
so
that
that
is
everything
that
I
had
to
present
today.
So
does
anybody
have
any
questions
or
anything
I'd
like
to
know
more
about.
B
E
Cool
well,
if
you
do
have
any
more
questions
at
any
point,
oh
I
should
have
mentioned.
Oh
there's,
two
other
things.
I
was
going
to
show
you
actually
in
this
context,
one
was
I
mentioned
that
we
have
I
mentioned
steps
we
and
I
mentioned
that
they
are
kubernetes
container
spec,
there's
actually
one
exception
to
that,
which
is
that
we
added
something
called
script
mode
that
lets.
You
basically
define.
Scripts
is
kind
of
like
first-class
things,
so
you
can
have
a
step
that
just
runs
like
a
bash
scripts.
E
It
runs
a
Python
script,
and
this
this
is
a
place
where
I
could
see
this
being
like
a
reusable
thing,
if
you
wrote
like
a
very
large
script
in
here,
of
course,
then
the
line
between
like
would
you
want
to
instead
publish
an
image
that
has
that
script
in
it.
It's
kind
of
fuzzy
and
I
also
wanted
to
show
you
what
a
task
looks
like,
and
this
is
this
is
not
a
real
task.
E
I
tried
to
update
this
to
have
kind
of
all
the
features
that
I
was
talking
about,
but
this
is
an
example
sort
of
an
example
of
a
task
that
would
run
some
tests
against
some
go
source,
so
it
would
declare
that
it
expects
some
files
to
exist
in
a
particular
path.
It
declares
parameters
that
you
can
pass
to
it
like
flags
that
you
want
to
pass
while
you're
writing
running
the
tests,
and
then
you
can
have
steps
this
one
only
has
one
step.
The
step
runs
a
golang
image.
E
It
runs
it
in
the
directory
where
you
put
your
source
and
then
it
runs
go
test,
and
then
this
is
totally
contrived,
because
this
thing
doesn't
actually
have
any
results,
but
you
can
declare
you
can
declare
values
that
you
would
actually
produce
afterwards,
which
I
don't
know
number
of
tests
run.
Maybe
I'm
not
sure,
if
that's
a
great
example
here
but
yeah.
E
If
you're
interested
in
learning
more
about
Tecton
or
engaging
just
with
Tecton
in
general,
we
have
a
community
repo
where
you
can
find
information
about
how
to
like,
join
our
slack
or
mailing
list
join
our
working
groups
yeah.
But
you
could
probably
see
in
this
presentation
that
the
goals
that
we
have
around
Tecton
are
kind
of
pretty
similar
to
the
goals
of
this
working
group.
E
So,
like
one
thing,
one
thing
that
could
be
interesting
to
do
I
think
we're
talking
at
the
beginning
of
this
meeting
about
how
to
create
like
kind
of
standard
represent
representations
of
things
like
pipelines.
It
could
be.
We
could
potentially
use
like
the
Tecton
definition
as
a
starting
point
for
conversation,
maybe
and
then
like
talk
about
what's
missing
from
there
or
what
not
right,
I
mean
or
or
we
could
take
it.
Another
direction
and
be
like
is,
is
the
image.
E
C
Been
dealing
with
with
the
folks
at
Jenkins,
X,
James,
Stratton
and
others
so
Jenkins
X
originally
was
a.
It
still
is
a
complete
CI
CD
that
definition
and
runtime
system.
They
were.
They
originally
based
their
CD
orchestration
on
Jenkins
pipelines,
which
has
its
own
language,
he's
assigned
its
own
DSL
and
later
on,
almost
I
want
to
say
late
last
year
they
decided
that
Jenkins
itself
is
just
not
server
less,
it's
not
that
they
decided
that
it
just
that
is
the
case,
and
they
wanted
to
go
with
something
that
is
native
to
kubernetes,
a
pipelining
mechanism.
C
C
C
C
Guess
what
you
have
to
do
to
that
translation
layer?
You
constantly
have
to
update
it
as
well
and
you'll
never
fully
catch
up.
So
we
are
standardizing
at
eBay,
our
CD
mechanism,
around
Tecton
CD,
and
if
any
other
groups
internally
want
to
use
jenkins,
x1
more
power
to
them,
they
can
do
that,
but
we
we
are
providing
support
for
tech
on
CD
itself
within
a
company
and
that's
what
we're
gonna
standardize
our
CTO
orchestration
on.
Hopefully
that
answers
your
question.
E
One
thing
that's
interesting
and
Traci
can
correct
me
if
I,
if
I
am
wrong
about
this,
but
we've
actually
been
talking
with
the
Jenkins
ex
folks
about
exposing
some
of
the
Tecton
types
more
directly,
so
like
specifically
being
able
to
support
the
catalog
in
Jenkins
X.
And
it's
something
that
we're
I.
Think
we're
planning
to
like
in
the
next
few
months,
actually
like
get
together
with
some
folks
who
work
on
Jenkins,
X
and
like
work
on
it
together
and,
like
add
support
for
the
catalog
Jenkins
X.
D
Sounds
good
I
like
I
like
Jeremy's,
summary
Tecton,
is
the
plumbing
Jenkins
access,
the
porcelain
and
I
think
it's
nice.
The
way
they
work
together
and
depending
on
your
use
case,
you
can
come
in
at
different
levels.
I
know
the
Jenkins
ex
use
case
is
sort
of
looking
at
applications
where
you've
just
got.
You
know
dozens
and
dozens
of
micro
services
and
you
just
want
high
plains
generated
for
you,
you're
not
going
to
be
there
kind
of
handcrafting
things
so
yeah,
it's
they.
C
So
Tracy
I
mentioned
this
to
James
and
as
well
that
having
one
of
the
best
things
that
can
happen
to
join
his
ex
is
that,
if,
if
they
would
adapt
the
definition
of
the
pipeline
to
the
technology
specs
and
and
stop
doing
any
translations
in
between
you,
you
will
never
catch
up.
So
if
maybe
you
could
make
that
point.
A
A
A
A
A
The
next
meeting
will
be
on.
Let
me
find
that
it
will
be
on
March,
5th
and
you'll
have
a
presentation
from
a
user
during
that
meeting.
David
Villa
Sonja
from
Orange,
and
they
are
heavy
users
of
gridlock
pipelines
and
they
have
been
doing
pretty
cool
stuff
because
they
are
heavily
involved
in
various
open
source
committees,
such
as
on
a
port
Network
automation
platform
and
all
PFE
open
platform
for
network
functions
organization.
A
I
suggest
you
to
join
to
that
meeting
and
see
what
they
are
doing
there,
because
it's
actually
similar
to
how
we
are
doing
in
Ericsson
with
different
open-source
communities,
and
it
is
very
difficult
for
us
as
users
to
bring
open
source
technologies
to
our
product
development
units,
because
all
these
communities
use
different
tools
and
yeah.
That
is
one
of
things
about
this:
seek
to
find
ways
to
improve
the
situation
so
March
5th.
That
presentation
will
take
place
and
then
I
will
send
the
minutes
of
the
meeting
tomorrow
and
sent
the
new
agenda
for
upcoming
meeting.