►
From YouTube: CDF SIG Interoperability Meeting 2020-07-23
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).
B
Where
are
you
at
not
so
sunny
wales
in
the
uk.
B
C
A
D
I
see
I
have
a
construction
happening
outside
my
house
today,
unexpectedly
by
the
city,
so
it's
quite
loud
right
now.
I
don't
even
know
if
that's
being
picked
up
and
you
can
hear,
but
in
case
it
gets
too
loud,
then
maybe
it
would
be
all
right
if
you
did
yeah.
A
A
A
A
Yeah,
it's
like
controls
can
be
improved,
so
the
link
is
on
the
chat
and
we
have
very
light
agenda
today.
We
will
start
with
action.
Item
reveal
followed
by
a
quick
discussion
on
the
road
map
which
we
moved
to
the
repo
it's
pull
request,
and
then
we
all
have
a
spinnaker
presentation
from
cameron
from
armory,
and
if
you
have
additional
topics,
you
can
add
them
to
the
agenda
and
we
can
spend
time
on
that
topic
today
as
well.
Given
the
light
agenda,
yeah,
I've
got
a
topic.
A
A
A
We
have
been
working
since
february
or
something
and
it
got
four
approvals
and
it's
been
there
since
two
weeks
and
I
suppose
we
can
merge
this
in
and
any
updates
we
need
to
do.
We
can
be
done
using
new
pull
quests.
D
A
A
E
So
it
was
something
that
came
up
in
jenkins
x,
so
folks
were
asking
for
an
official
helm
chart
for
tekton
pipelines,
and
this
is
a
long
issue,
but
I
think
where
it
got
to
is
that
jenkins
x
actually
maintained
a
helm
chart
for
techton
and
the
teclon
folks,
you
know,
were
not
too
fussed
about
having
that
in
the
tecton
project
itself.
E
But
if
we
go
down
the
comments,
someone
made
a
suggestion.
I
think
maurizio
salatino
that
we
might
want
to
push
for
something
like
cd
foundation
to
maintain
the
chart
as
a
joint
collaboration
of
multiple
open
source
projects
interested
in
having
the
charts
and
then
he
bring
that
to
james
rawlings
and
jim
says
it
makes
sense.
E
So
I
would
like
to
think
about
yeah.
If
we
could
do
that,
and
does
it
make
sense,
first
of
all
to
have
it
in
that
place.
What
would
it
look
like
beyond
just
creating
it
city
of
having
this
library
or
film
charts
and
yeah?
I
think
I'd
love
to
get
people's
opinions
and
then,
if
it
seems
like
it
makes
sense,
and
we
can
think
through
kind
of
how
it
would
work,
then
I
can
go
ahead
and
try
to
get
it
done.
B
Just
just
for
what
it's
worth
I
mean
jenkins
x
is
currently
using
a
little
older
one,
so
I
think,
would
be
good
to
have
one
that
tracks
the
latest
tecton
anyway,
and
just
from
a
technical
point
of
view,
you
could
use
just
the
github
repo
as
the
to
host
the
get
the
helm
chart
as
well.
What
I
mean
by
that
is,
I
don't
think,
you'd
need
much
else.
You
wouldn't
need
a
chart.
Repository,
for
example,
I
think
we
could
just
do
in
the
git
repository
would
be
enough.
B
Yeah
well,
you'd
probably
want
a
separate
helm,
separate
repo
per
helm
chart.
So
maybe
it
would
be
yeah
detect
on
the
helm,
charts
and
something
along
those
lines,
and
then
it's
it
would
be
about
how
how
the
things
how
to
changes
get
notified,
because
you'd
want
to
keep
the
image
there
to
type
the
image
tags
in
that
git
repository
automatically
up
to
date,
and
ideally,
you'd,
have
some
automated
testing
around
that.
As.
E
Well,
okay,
and
I
don't
think
that's
too
unreasonable-
I
mean
we've
already
got
a
couple
of
repos
which
have
code
for
things
like
the
cicd
landscape
and
some
parts.
Rarely
going
around
doing
that,
and
so
you
mentioned
it's
not
just
a
case
of
taking
the
one
from
jenkins
x,
but
updating
it
or
how
would
you
approach
it.
B
I
would
personally
probably
there's
nobody
from
the
tecton
project
on
the
line.
I
guess
so
in
the
moment
so
yeah
we
could.
We
could
start
with
that
as
a
good
basis.
We've
been
using
that
on
jenkins
x,
I've
noticed
somebody
mentioned
that
there's
another
link
for
another
helm
chart.
So
maybe
we
do
a
diff
of
the
two
and
just
to
ch,
just
to
check
mention
it
on
to
the
tecton
slack
channel
to
say
look,
this
is
what
we're
thinking
and
anybody
got
any
other
thoughts.
What
should
be
in
there.
E
And
does
that
make
sense
in
the
context
of
this
interoperability
group
that
it's
like
cgf
is
the
owner
of
these
things
or
the
place
to
house
things
that
fall
across
the
boundaries
of
different
projects?.
A
I
I
think
it
it.
It
makes
sense
because,
like
this,
like
it's
similar
to
the
goal,
scm
discussion
we
had
few
weeks
ago
like
there
is
no
clear
owner
and
the
comedy
is
like
they-
I
don't
know
they
may
not
be
they.
They
may
not
be
sure
about
how
to
handle
them
because
they
don't
feel
they
own
that
thing,
because
it's
like
cross-community
type
of
thing
and
we
now
we
have
two
examples
we
can
perhaps
you
know,
propose
something
to
talk,
because
talk
should
be
aware
of
this.
A
Isabel
cdf
talk
and
we
can
say
this
is
kind
of
under
interoperable
topic,
and
this
is
the
way
we
want
to
approach
this,
like
this
type
of
libraries
or
the
people.
Maintaining
these
libraries
can
come
and
present
their
case
to
the
sikh
and
suggest
yeah,
it's
great.
Let's
reach
out
to
cdf
operations
and
get
a
repo
for
you,
and
then
those
people
who
actually
bring
the
topic
become
maintainers
of
that
and
anyone
from
the
sikh
and
wider
cdf
could
contribute
to
those
reports.
E
Yeah
I
like
that,
as
a
kind
of
overview
of
the
process,
great
anyone
else,
you
know
chime
in
with
any
thoughts.
C
Whatsoever,
just
I
had
a
q
hi,
I'm
dave
sudia,
I'm
joining
for
the
first
time
today.
I
just
had
a
quick
question
on
why
lots
of
repos
or
a
repo
per
project
versus
a
larger
repo
that
holds
many.
B
Yeah,
I
guess
I
mean
that's
to
it's
a
good
question,
because
it's
probably
coming
from
a
jenkins
x
mindset
that
one
we
tend
to
tag
release
every
single
moves
to
master.
B
We
tend
not
to
not
to
use
monoliths
on
that,
so
you,
then,
if
you,
if
you
merge
a
pill
request
into
into
your
master
branch,
you
then
need
to
re-release
all
the
charts
inside
that
git
repository
so
they'd,
all
if
you
updated
one
chart
another
chart
would
also
get
a
version
upgrade
as
well
so
but
that,
but
the
images
inside
it
may
not
have
changed.
B
So
that's
typically,
how
jenkins
x
does
performance
releases,
this
kind
of
trump-based
development
at
trump-based
development
and
making
sure
that
yeah
you
release
on
every
motion
master.
F
F
Targeted
repos
are
best
practice
anyway,
you
want
to
have
as
little
in
the
repo
that's
targeted
towards
a
particular
function,
and
that's
it
so
when
it
when
things
change-
and
you
have
to
rebuild,
if
you've
got
it
hooked
up
to
a
cd
pipeline,
it
only
builds
that
function
and
that's
it
and
nothing
else,
and
not
the
entire
world.
C
E
Yeah,
I
think
it's
a
great
question
and
I
enjoyed
hearing
the
answers.
I
think,
as
a
separate
kind
of
topic
we're
getting
to
a
point
at
cdf,
where
I
think
we're
going
to
be
having
more
of
those
discussions
around.
E
You
know
what
our
best
practices,
especially
when
we're
talking
about
kind
of
modern
ci
cd
and
what
are
the
implications
of
those
practices?
What
additional
tooling
do
we
need
to
support
them
because,
I
think
yeah,
I
think
many
people,
myself
included,
would
approach
it
for
you
know
why
not
just
have
one
repository
and
dump
a
whole
bunch
of
stuff
in
there
rather
than
proliferate.
B
Yeah
there's
some
of
something
just
as
a
I
guess.
A
side
note
talking
point
jenkins
x
is
doesn't
have
great
support
for
for
mono
repos,
it's
something
we'd
want
to,
but
it
does
come
down
to
only
true
like
the
google
projects.
B
They
have
these
great
monument
reapers
and
they
have
things
like
basil
that
only
only
build
certain
parts
of
the
tree
based
on
certain
changes.
I
don't
think
we've
got
anything
quite
advanced
as
that.
Yet,
but
something
love
to
see-
and
I
think
maybe
with
that
it
would
help
the
point
you
make
david
and
maybe
we
could
make
use
of
one
repose
potentially
because
I
know
some
people.
I
think
it's
a
bit
like
marmite.
Some
people
love
them.
Some
people
hate
them
so.
E
Hey
great,
so
I
think
from
all
that
discussion,
my
next
steps
will
be
to
sync
with
somebody
from
the
tecton
community,
either
christie
or
anyone
else
who
wants
to
weigh
in
and
just
give
it
a
stamp
of
approval
and
then
just
take
that
to
the
talk
and
get
that
set
up
but
make
sure
ultimately
the
talk
oversees
any
any
process
or
governance
around
it
and
yeah.
B
For
what
it's
worth,
I
think
that
could
also
pave
the
way
for
other
things
that
we've
talked
about
in
the
past:
around
specifications,
the
shared
metadata
things
like
environments
and
or
whatever
what
the
environment
is
and
having
kind
of
specifications
that
we
can
have
a
report,
something
there
that
actually
generates
these
specs
as
well
easily
to
consume
by
from
providing
interrupt
between
different
projects.
They
could
consume
these
these.
C
So
the
the
other
bit
of
support
I
put
forward
for
this
is
just
again
so
you
know
I'm
on
a
team
of
three
and
the
company
I'm
in
and
we
for
the
most
part,
rely
on
pre-built
things
for
any
tool
that
you
know
we're
not
making
and-
and
it's
always
hard
to
we're,
putting
we're
doing
the
like
a
prometheus
adapter
in
our
kubernetes
cluster
this
week
and
it's
by
direct
x-man
12
and
he's
very
talented.
But
it's
like
anything
that
comes
from
you
know
the
cdf
or
whatever
is
gonna.
C
E
That's
great
feedback
and
yeah.
Now
I
think,
underlines
you
know
the
responsibility
cdf
should
have
as
well
to
keep
things
in
a
good
state
and
well
maintained
and
kind
of
example,
of
best
practices
and
just
as
a
side
note
david,
I
don't
know
how
much
you've
seen
of
past
meetings
and
what
we
do
here.
But
we
love
folks
who
are
happy
to
talk
about
what
they're
doing
maybe
do
presentation
or
a
demo.
E
I
just
want
to
see
some
thoughts
if
you
do
have
some
aspect
of
what
you
and
your
team
are
doing,
that
you're
able
to
and
would
like
to
share
and
help
get
you
scheduled
in
for
an
upcoming
meeting.
C
B
E
E
A
A
Just
making
them
visible
would
be
a
contribution
forget
about
like
making
them
better
because,
like
all
of
us
are
having
like
needs
in
similar
areas
and
just
listing
them
and
pointing
to
their
repositories
and
people
who
are
contributing
to
those
could
have
people
to
find
those
things
rather
than
looking
at
personal
repositories
and
googling
things.
But
that
could
be
a
great
like
make
lives
of
many
people
a
lot
better.
So
yeah
just
want
to
share
that.
E
On
the
go
sem
well,
I
was
going
to
ask
hara.
I
know
you
carry
you
shared
a
little
update
on
the
directions.
I
wondered
if
you
could
share
that
with
the
group,
just
as
no,
it's
not
fallen
off
our
reader.
D
Yes,
so
I
I've
contacted
the
go
sem
drone
folks
essentially,
and
they
are
open
to
attending
one
of
the
same
meetings
and
we
can
arrange
that
I
do
need
to
set
it
up,
maybe
with
some
tech,
town
folks
and
just
organize
what
we
will
discuss
with
them,
and
then
I
wasn't
sure
from
our
side
how
much
we
were
building
out
this
library
of
different
projects
or
utilities
that
that
are
used
across
projects.
D
But
if
we
are
moving
forward
with
it-
and
you
know
this
official
home
chart
for
texting
would
be
like
it's
great
like.
I
think
that
helps
us
to
discuss
that
more
clearly
with
the
drone
folks,
as
we
begin
to
build
out
this
library,
we
know
more
to
say
to
them,
but
I
can
move
forward
with
contacting
them.
I
yeah
and
maybe
we'll
need
to
liaise
with
you
tracy
about
contacting
all
the
tech
town
folks
as
well.
I'm
calling
them
in
does
that
sound
good.
A
G
And
hey
everyone,
I'm
cameron-
I
am
a
software
engineer
over
at
armory,
and
I've
been
working
on
the
spinnaker
project
for
about
the
last
year
and
a
half
ever
since
I
I
joined
armory.
So
this
is
my
first
time
working
in
an
open
source
project
just
to
give
some
some
background.
Let's
see,
I'm
the
tech
lead
for
the
extensibility
team
at
armory,
as
well
as
the
co-lead
for
the
platform
sig
for
spinnaker
I'm
joined
today
by
ryan
he's
the
pm
who
is
working
on
our
team.
G
Yes,
cool,
sweet
all
right,
so
I
just
want
to
give
a
really
quick
overview
of
what
spinnaker
is
and
just
high
level
really
really
high
level.
This
will
probably
look
pretty
familiar
to
everyone.
We
have
micro
services,
so
spinnaker
itself
is
comprised
of
10
microservices,
there's
different
microservices
for
different
pieces
of
functionality
right
so
in
this
architecture
diagram
we
have
on
the
right.
We
have
the
items
in
green
which
are
interactable,
I
guess
microservices.
G
So
we
have
deck,
which
is
our
front
end,
and
then
we
have
anyone
else
who
wants
to
be
an
api
caller.
You
hit
the
the
dex,
the
gate
service.
Apologies
all
in
all,
there's
just
a
lot
of
microservices
and
contributing
to
the
project
is
not
actually
the
easiest
because
of
all
these
micro
services
going
on.
So
what
does
spinnaker
do?
Well,
you
can
configure
and
run
pipelines.
G
Pipelines
are
comprised
of
stages
and
tasks.
I
watched
an
earlier
episode.
Maybe
episode
is
not
the
right
term,
but
I
watched
an
earlier
recording
of
one
of
these
meetings
and
it
looks
like
there's
some
good
terminology
around
the
different
projects
talking
about
pipeline
stages,
tasks
and
how
they
relate
to
you
know
techton
and
terminology.
So
we
use
the
idea
of
stages
and
tasks
and
pipeline
is
the
overall
arching
object
that
contains
those
so
spinnaker
itself,
you
you
run
pipelines,
pipelines,
deploy
your
infrastructure
within
spinnaker,
you
can
view
and
manage
your
infrastructure.
G
So
it's
pretty
cool,
you
can
say,
hey,
look.
I've
got
all
these
kubernetes
clusters
and
they're
running
all
these
pods
and
you
can
see
it
within
spinnaker
itself.
You
can
also
view
logs,
so
it's
a
pretty
nice
one-stop
shop
for
a
bunch
of
sdlc
type
work.
G
So,
let's
go
on
so
I
just
want
to
talk
about
the
evolution
of
extensibility
within
spinnaker,
because
spinnaker
itself
has
been
designed
as
a
extensible
project
from
the
start,
but
that
means
extensibility
is
means
different
things
at
different,
let's
say:
stages
of
a
project's
life
cycle,
so
when
spinnaker
first
came
out-
and
this
is
how
a
lot
of
people
will
extend
projects
in
the
early
days
of
a
project-
spinnaker
basically
publishes
all
the
open
source
jars,
so
anyone
can
consume
them.
G
So
the
idea
of
extending
spinnaker
in
the
past
has
been
hey.
Pull
in
these
open
source.
Jars
add
some
custom
code.
On
top
of
it
manage
your
own,
builds
your
own
releases
and
you're
off
to
the
races.
It
requires
a
bunch
of
java
knowledge,
as
well
as
deep
knowledge
of
the
architecture.
I
showed
above
where
I
showed
earlier
so
this
is.
This
is
great.
There's
not
much
sharing
of
extension
code
between
different
groups
running
spinnaker
right.
G
This
is
everyone
has
their
own
spinnaker
installation
that
they
have
customized
for
their
for
their
own
purposes.
Everyone
had
to
figure
out
their
own
way
of
building
their
own
way
of
releasing
etc
cetera.
G
G
So
we
added
a
stage
called
the
run
job
stage
and
essentially
what
the
run
job
stage
is.
You
can
run
any
kubernetes
job
as
a
as
a
stage,
so
there's
inputs
right
to
a
stage
and
then
there's
outputs
both
in
terms
of
key
value
pairs
as
well
as
artifacts.
So
this
was
great.
G
Any
user
of
spinnaker
could
create
a
pipeline
assuming
you
have
the
correct
permissions.
Of
course
you
can
configure
your
pipeline
and
push
up
a
container
to
do
some
job
that
you
call
via
this
run
job
stage.
G
It
was
pretty
customizable.
You
can
write
in
any
language.
You
want,
you
run
a
container
inputs,
outputs
off
to
the
races
right.
So
this
was
great.
This
was
fortunately,
and
unfortunately,
let's
say
different
use
cases
right,
it's
configured
per
pipeline.
So
if
you
want
to
share
this
within
your
organization,
that
was
not
an
easy
thing
to
do.
G
Each
team
would
configure
their
own
pipelines.
You
know
from
what
I've
seen
users
do.
Different
teams
would
configure
their
own
pipelines
and
they
would
have
their
own
run.
Job
stages
accustomed
to
their
team,
but
then
central
devops,
tooling,
teams
wanted
to
have
best
practices,
kind
of
built
in
and
shared
amongst
their
organization.
G
So
let's
go
on
to
the
next
slide,
so
we
have
this
idea
of
a
custom
job
stage,
so
this
is
a
little
bit
different
rather
than
having
end
users
app
developers
create
containers
and
use
them
within
their
pipelines.
G
What
that
means
is
that
stage
is
now
available
within
spinnaker
as
a
native
stage,
so
you
can
add
another
stage
and
the
ui
is
present
and
it
looks
all
native
and
works
nicely
within
within
spinnaker.
So
that's
a
great
way
of
sharing
best
practices
amongst
your
organization.
This
was
not
easy,
though,
to
share
across
organizations.
G
G
I
don't
know
that
the
name
is
is
great
pf
or
jpf
for
java.
So
it's
kind
of
recursive,
I
guess
added
to
spinnaker
by
the
team
operating
spinnaker.
So
again
that
is
like
the
central
devops,
tooling
team
will
add
a
plug-in
to
the
running
spinning
for
installation
and
then
the
whole
organization
can
take
advantage
of
that
functionality.
G
G
The
idea
that
we've
been
trying
to
push
with
the
plug-in
framework
is
we
want
to
lower
the
barrier
of
entry
for
extending
spinnaker
functionality,
as
I
showed
earlier,
spinnaker
is
kind
of
a
beast,
and
it
we
would
like
to
lower
that
the
barrier
of
entry
there
so
right
now
adding
to
the
plug-in
framework.
It
does
require
java
or
kotlin
knowledge,
and
if
you
want
to
have
a
front
end
component,
it
does
require
some
react.
Knowledge.
G
So
this
is
an
example
of
some
how
some
plug-ins
would
work
within
spinnaker.
We
have
a
couple
of
these
written
today,
so
there's
a
the
idea
of
a
custom
stage
plug-in
and
you
can
see
in
the
case
of
adding
an
additional
cloud
provider
to
spinnaker,
which
is
a
piece
of
code
that
will
interact
and
mutate
the
cloud
you
would
have
a
ui
portion,
that's
written
in
react
and
that
is
relevant
to
the
deck
piece
of
code.
The
deck
service.
G
There's
an
orchestration
portion
you're
going
to
have
to
create
the
stage
object
itself
which
oops
which
lives
in
oops,
which
lives
in
orca
the
stage
object
and
then
there's
a
piece
of
functionality
about
interacting
with
the
cloud
and
that
would
be
added
to
cloud
driver.
So
part
of
the
reason
we
wanted
to
do.
The
plug-in
framework
is
have
all
this
functionality
be
co-located
within
one
repo,
rather
than
having
a
pr
to
deck,
a
pr
to
orca
and
a
pr
to
cloud
driver
or
three
separate
plug-ins.
G
You
have
one
plug-in
repo
and
all
this
all
the
feature
code
is
code
located
together.
So
that's
an
example
of
a
of
a
custom
stage.
We
will
also,
we
also
have
things
like
different
types
of
notification
listeners,
so
we
can
send.
G
Send
metrics
or
consume
metrics
from
different
different
providers,
so
spinnaker
itself
produces
a
bunch
of
metrics.
We
can
send
those
metrics
through
echo
to
any
different
provider
we
choose.
So
what
we've
been
doing
is
throughout
the
code
we've
been
adding
these
extension
points
or
long-term
contracts
in
a
certain
package
with
within
each
of
these
projects,
all
the
code
that
goes
in
there.
All
the
interfaces
are
considered
long
term
stable,
and
we
want
to
ensure
that
those
are
are
stable
contracts
for
developers
to
build
against.
G
Let's
see
one
thing
I
wanted
to
to
mention
with
spinnaker
extensibility,
not
with
the
plug-in
framework
actually
itself,
but
within
so
all
these
microservices
have
a
shared
library
called
cork
that
that
they
all
consume
this
library.
Cork
has
the
plugin
code
on
the
plugin
framework
code
there,
which
is
why
all
the
services
have
the
plug-in
functionality.
G
It
has
quark
itself.
The
library
has
more
than
just
plug-in
functionality
in
there.
However,
it
also
has
functionality
like
secret
engines,
so
all
these
services
know
how
to
decrypt
secrets.
So
you
can
point
to
a
secret
in
vault
and
say:
hey
cloud
driver.
Your
cube,
config
file
is
over
there
in
vault.
We
don't
have
to
have
it
checked
into
to
get
so
you
can
have
a
good
ops
workflow.
Why
am
I
bringing
this
up?
G
Well,
what
we
noticed
with
the
project
and
one
of
the
reasons
why
this
plug-in
framework,
I
think,
is
so
so
cool
is
we.
We
noticed
that
another
company,
I
believe
it
was
nike
they
had
took
our
they
brought
in
our
cork
library.
Not
even
they
didn't
have
anything
to
do
with
spinnaker.
They
they
said:
hey,
there's
this
cool
secret
engine
library,
let's
use
it
and
build
on
top
of
it.
G
So
this
was
just
an
interface
in
a
library
that
we
had
in
our
in
in
a
shared
library
for
spinnaker
and
they
took
it
they
built
on
top
of
it
and
they
contributed
the
the
secret
engine
back
to
the
spinnaker
project.
So
that
was
really
cool
to
see.
Like
hey
this
piece
of
functionality,
we
wrote
this
interface
of
a
secret
engine,
it's
useful
for
not
just
within
the
spinnaker
project,
but
within
whatever
type
of
project.
You
want
to
use
that
decrypts
secrets.
G
So
I
thought
that
was
an
interesting
story,
especially
for
the
interoperability
sig.
It
would
be
really
cool
if
we
could
have
different
plugins
or
types
of
functionality
that
we
could
just
kind
of
pass
between
each
other
cool,
so
next
steps
and
future
directions.
So
far,
what
we've
been
shooting
for
is
this
lean
core
and
expansive
ecosystem.
G
So
the
lean
core
part
we
have
not
been
focusing
on
as
much
we've
been
focusing
on
adding
ways
to
add
additional
functionality.
Soon,
we
want
to
start
focusing
as
well
on
slimming
down
the
features
that
are
in
the
core
product
offering
and
ripping
out
not
non-core
functionality
into
interference.
G
We
want
to
continue
lowering
the
cost.
The
barrier
of
entry
to
extending
spinnaker
and
one
of
the
main
things
we
want
to
do
is
get
away
from
forcing
people
to
run
or
write
their
plugins
in
java
or
kotlin.
So
we
want
to
move
towards
extending
spinnaker
via
apis,
so
we're
doing
a
lot
of
the
foundational
work
right
now
in
order
to
do
that,
and
hopefully
we'll
be
seeing
that
in
the
in
the
future,
any
questions.
F
Yeah
thanks
very
much
for
that
presentation,
that's
great
to
hear
that
the
spinnaker
monolith
is
being
worked
on
and
in
this
effort
to
to
to
to
break
it
up
me
and
my
company.
We
we
did
a
pretty
extensive
evaluation
of
spinnaker
end
of
2018.
I
know
that's
a
year
and
a
half.
F
Well
now
you
know
a
year
and
a
half
ago,
but
at
the
time
or
soon
after
that,
we
were
told
that
orca
the
orchestration
engine
was
in
the
process.
Our
armory
was
in
the
process
of
replacing
that
with
something
else,
perhaps
with
tecton
did
that
work
now
this
this
question
has
nothing
presented,
but
did
that
did
that
ever
go
through.
G
That
did
not
go
through,
however,
we've
we've
talked
about
it
and
I
not
speaking
for
a
spinnaker
at
all
or
armory.
That's
something
that
I
think
would
be
a
pretty
cool
integration
and
thing
to
have.
I
don't
think
we're
tied
to
our
our
pipeline
format
in
in
any
sense,
that's
not
necessarily
something
that
is
our
our
bread
and
butter.
Let's
say
so,
yeah
moving
towards
tecton
would
is
definitely
something
I
think
we're
interested
in
doing
whether
we
have
the
time
or
or
whether
we
prioritize
that
is.
G
That
is
another
question,
but
I
think
joining
these
meetings,
the
interoperability,
sig
meetings
and
learning
more
about
how
we
could
take
advantage
of
that
would
give
us
maybe
more
ammo
to
help
drive
the
project
in
that
direction.
E
You
you
know
just
adding
to
that.
I
think
we're
in
this
interoperability
group
and
certainly
done
lawrence.
Our
top
chair
he's
trying
to
figure
out
how
we
can
have
more
of
a
kind
of
interoperability
summit
which
brings
folks
together
and
of
all
the
different
projects.
So
we
can
just
hash
things
out
and
figure
out
how
to
make
things
easier
if,
if,
let's
say
checked
on
integration
or
just
integration
across
projects
and
understanding,
what
each
project
has
that
others
could
use.
G
Yeah
totally
yeah
we'd
love
to
collaborate
that
that's
what
we're
that's,
what
we're
trying
to
do.
B
Just
a
this
is
a
great
question.
Would
you
I
guess
you
mentioned
about
moving
more
to
apis?
Would
you
see
future
plugins
being
non-java
based.
G
Yeah,
that's
that's
the
idea.
So
right
now,
there's
there's.
There
is
a
method
of
doing
non-java
based
or
half
and
half
where
you
can
write
a
portion
of
your
plugin
in
java.
That
is
the
stage
part
and
you
can
have
that
call
out
to
whatever
your
services.
G
G
We
have
some
internal
plugins
that
or
some
internal
features
that
we
actually
will
put
in
a
another
container
within
the
spinnaker
cluster
and
talk
to
that
and
and
so
we're
working
on
figuring
out
how
we
want
to
do
that
going
forward
because
you
know
if,
let's
how
should
I
say
this,
your
services
need
to
be
able
to
talk
to
the
other
services
within
within
spinnaker.
So
there
might
be
some
deployment
concerns,
so
we're
kind
of
figuring
all
that
out.
But
the
idea
is
yes.
G
B
That's
awesome,
so
I
work
on
jenkins
x
and
it
would
be
really
loved.
I
mean
almost
what
tracy
was
saying:
I'd
love
to
see
some
kind
of
nice
integrations
and
and
because
we
actually,
we
use
tecton
already
as
well
so
try
and
understand
where
those
those
lines
could
be
drawn,
but
I
think
it'd
be
really
interesting
to
look
at
some
integrations.
B
So
just
one
natural,
quick
other
follow-up
question
is-
and
this
may
be
a
silly
question-
so
apologies
is
presumably
sp.
Spinnaker
is
still
is
a
large
focus
of
speeding.
Care
is
non-container.
Based
is
that
right.
G
Let's
see
so
that
there,
I
think,
there's
two
different
parts
of
that
one.
Let's
see
the
way
that
I
see
most
people
running
spinnaker
itself
is
in
kubernetes
container
based
now
the
targets
are
not
always
kubernetes
or
container-based
yeah.
So
that's
correct.
It's
a
multi-target
multi-cloud
platform.
Where
you
can
write,
you
can
deploy
your
workloads
to
different
types
of
clouds
like
yeah,
but
that's
correct.
Okay,
so.
B
G
That
you
know
different
plug-ins
can
hopefully
help
people
move
from
their
old,
the
old.
You
know,
data,
centers
and
everything
to
the
cloud.
The
idea
with
plugins
is
hey.
They
might
have
some
sort
of
functionality.
That
is,
you
know
some
service
that
is
really
custom
to
their
their
company,
their
organization,
and
they
don't
necessarily
want
that
to
be
put
into
the
core
offering
they
also
don't
want
to
maintain
their
own
build
and
release
process
just
to
so
they
can
release
their
code.
B
Interestingly
enough
yeah
one
jenkins
x's
areas
is
we.
It
is
mainly
deployments
to
to
kubernetes,
so
I
could
definitely
see
some.
I
mean
some
integration,
whether
that's
in
the
form
of
plug-in
or,
however,
it
might
look
to
be
able
to
support
the
vast
number
of
integrations
that
spinnaker
has
to
be
able
to
deploy
out
to
you,
know,
amazon
or
anywhere
non-container-based
non-cuban
based
deployments.
G
Yeah,
I
think
I'll
be
joining
more
of
these
in
the
future.
E
E
G
A
great
that's,
a
great
question,
so
we're
we
kind
of
surveyed
who
would
be
creating
plugins
right,
who
would
be
the
the
users
creating
plugins
and
a
lot
of
the
times
it
kind
of
comes
down
to
the
central
devops,
tooling
teams
and
they're
focused
mostly
on
python,
and
go
live
from
what
we've
seen
bash
of
course
as
well.
But
ideally,
people
are
writing
plugins
more
in
in
more
type
languages
or
solid
programming,
languages.
G
Yeah
we've
gotten
that
feedback
that
not
everyone
wants
to
program
in
java
these
days.
E
I
was
I
used
to
work
in
the
eclipse
ecosystem
and
it
was
the
same
thing
and
python
was
motivated
by
all
these
folks
kind
of
doing
data
science
and
integrating
there,
and
we
ended
up
doing
like
there's
a
platform
called
py4j
which
is
a
python
to
java
and
just
using
that
as
a
way
to
get
a
quick
bridge.
Just
yet
pretty
pretty
nice
connecting
the
interpreted
language
to
java
and
all
the
fun
that
comes
with
that.
H
It's
also
potentially
an
interesting
way
to
get
our
the
persona
who
we
typically
think
of
as
an
end
user
of
spinnaker,
because
most
it's
usually
spring
boot
developers,
java
developers
of
different
ilks,
and
so
now
they
have
an
opportunity
to
actually
contribute
via
this
plugin
system,
which
you
know
there's
I
mean
that's
a
huge
community
to
tap
into
so
it's
an
interesting
experiment.
G
Yeah
and
you
know
actually
speaking
of
community-
I
guess
so-
we've
been
running
this.
We
call
it
a
gardening
days
event,
so
it's
this
whole.
Last
week
we've
been
having
a
we
had
a
kickoff
session.
I
guess
where
we
had
a
couple
meetings
where
we
spun
up
a
kubernetes
cluster
and
gave
attendees
access
to
their
own
namespace
that
they
have
access
to,
for,
I
think
about
a
week
or
so,
and
it's
kind
of
like
a
hackathon
but
a
laid-back
hackathon.
G
So
it's
like
you
work
on
your
projects
the
whole
week
and
then
at
the
end
there
is
a
short
hackathon,
but
we've
we've
done
two
of
these
now
and
at
the
the
first
time,
the
plug-in
system,
the
plug-in
framework
was
pretty
it's
in
like
a
early
stage
and
not
too
many
people
created
plugins,
but
we
did
have
some
some
early
partners
in
that
creating
plugins
this
second
time
we've
been
doing
it,
the
documentations
improved
a
bunch.
We
had
some
more
trainings
and
some
more
workshops,
and
it
it's
been
really
great
to
see.
G
There's
a
lot
more
teams
just
hopping
on
and
building
plug-ins.
They
don't
have
to
know
everything
about
spinnaker,
they
just
say
hey.
I
need
to
implement
these
two
interfaces
and
I'm
off
to
the
races.
I
have
a
new
stage
now
and
it
feels
really
good
to
them
too.
Like
hey,
I
actually
did
something,
and
I
contributed
this
this
functionality.
Without
being
a
you
know,
networking
expert
or
whatever
you
you
know,
might
think
you
have
to
be
in
order
to
contribute
to
an
open
source
project.
A
So
if
you
could
send
the
presentation
you
just
shown
us
to
the
repo
I
linked
in
the
chat
as
a
pr,
so
people
can
pull
down
the
slides
and
look
at
them
offline
again,
please
welcome
to
our
upcoming
meetings
as
well.
As
you
know,
as
you've
seen,
we
have
users
and
different
projects
are
represented
here
and
spinnaker.
A
E
I
had
one
and
just
something
to
share
so
speaking
of
like
techton
integration
on
the
jenkins
side
of
the
house.
There
is
a
presentation
in
the
jenkins
community
it's
tomorrow
and
it's
a
techton
trigger
plug-in
proof
of
concept.
E
E
So
it's
7
a.m,
eastern,
so
a
bit
early
for
me,
but
we
are
going
to
try
and
encourage
them
to
maybe
reproduce
that
demo
in
this
group
or
bring
that
discussion
here
as
well.
So
yeah
we
can
start
to
see
what
jenkins
and
tectonic
integration
might
look
like.