►
From YouTube: 2021.1.15 Cloud Native SIG: Discussion on Tekton Client plugin and proposed Cloudevents plugin
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
B
Yeah
so
from
I'll
introduce
myself,
I'm
gareth
evans.
I've
come
from
the
jenkins
x
project,
where
we
used
tekton
quite
a
lot.
We're
sort
of
heavily
heavily
heavy
heavy
uses
of
tecton
really
and
recently
moved
over
to
jenkins
community,
mainly
focusing
on
sort
of
infrastructural
stuff
at
the
moment.
But
one
of
my
sort
of
areas
of
interest
is
the
tecton
stuff
and
I
would
love
to
know
how
that's
going.
Is
it
still
in
sort
of
active
development
or
is
it
sort
of?
C
C
So
we
package
jenkins
for
openshift
and
we
do
some
prescripts,
so
we
I
maintain
that,
along
with
that,
I
also
work
on
the
jenkins
automation
operator,
so
we
basically
were
working
on
the
kubernetes
operator
under
the
jenkins
cro
and
then
we
forked
from
them,
because
the
development
was
a
little
too
slow
for
us.
So
we
fought
from
them
into
the
jenkins
automation
operator
and
we
are
working
on
that
now
and
as
a
side
thing.
So
that
is,
that
is
the
stuff
I'm
doing
foreign
as
a
site
projects
technology.
C
I
started
as
a
site
project
to
better
understand
the
plugins
themselves
and
how
to
write
one,
because
at
the
end
of
the
day
I
have
to
understand
plugins
better
and
the
plugins
that
I
have
in
red
hat.
I've
inherited
them.
I
didn't
write
them
myself,
so
it
came
about
as
that.
So
one
thing
that
I
wrote
techno
plan
plugin
was
also
for
so
that
jenkins
users
can
basically
start
using
tecton
and
they
can
easily
just
you
know,
go
through.
They
wouldn't
have
to
fiddle
with
the
yama.
They
are
jenkins.
C
Users
are
okay
with
using
the
jenkins
ui
and
they
would
rather
do
that
right.
So
they
would
rather
just
like
go
to
the
jenkins
ui.
Do
some
stuff
on
the
jenkins
you
and
just
say
like
build
and
that's
what
they
are
used
to,
so
they
should
be
able
to
do
that
on
jenkins.
So
that
was
the
initial
idea
and
it
is.
C
It
is
in
development,
active
development,
but
it
is
also
something
that
I
do
on
the
side.
So
I
I
am
yeah.
It
would
be
nice
to
have
contributors,
it
would
be
faster
and
where
I
see
the
plugin
going
is
I
want
to.
I
wanted
to
be
able
to
support
all
tecton
api,
and
that
also
means
that
there
needs
to
be
some
kind
of
contribution.
C
So
you
know
we
have
all
the
api
supported
in
jenkins
and,
as
time
goes
on,
it
would
be
nice
to
have
event
listener
support,
and
once
once
that
happens,
and
if
the
cloud
cloud
events
plugin
works
out,
this
is
all
like
like
in
the
future
like
this
is
what
what
I
was
just
thinking
about.
So
if
the
cloud
events
plug-in
works
out,
the
the
tecton
client
plug-in
could
do
a
lot
of
stuff
through
the
cloud
events
plug-in
like.
C
So
there
would
be
like
a
heart
depending
dependency
on
the
cloud
events
plug-in
at
that
point.
But
then
that's
what
the
cloud
events
plug-in
like
I'm
ideating,
the
cloud
is
looking
for,
because
once
the
cloud
events
plug-in
is
done,
jenkins
can
support
cloud
events
and
work
with
them
and
there
is
a
proper
methodology
for
it.
C
You
know,
have
a
dsl
for
it
and
once
it's
in
the
jenkins
file,
I
I
see
that
that
would
be
like
a
good
plateau
to
reach,
because
then
then,
once
it
reaches
that
plateau,
then
a
lot
of
people
can
actually
start
incorporating
it
more
into
their
work,
jenkins,
workflows,
so
yeah.
That
is
basically
it.
That
is
basically
all
I've
thought
about.
It
yeah
it's
nice
to
see
some
interest
towards
it.
C
B
B
That
can
be
quite
quite
a
lot,
so
we're
looking
at
a
way
of
sort
of
running
those
builds
with
you
know
in
a
lighter
way,
if
possible,
and
one
of
the
things
we
found
on
the
jenkins
x
project
was
that
as
soon
as
we
switched
to
techton,
we
got
amazing
build
density
straight
out
of
the
box.
Just
because
the
builds
are
so
quick,
they're,
so
lightweight.
B
B
But
then
I
still
have
the
overhead
of
trying
to
need
to
spin
up
an
agent
first
to
be
able
to
do
that
and
that's
problematic
or
I
take
over
an
executor
on
the
on
the
controller
and
that's
what
I'm
kind
of
trying
to
avoid
yeah.
I
mean
one
of
the
approaches
we
took
on
jenkins
x
was
to
have
it's
not
actually
jenkins
x.
B
The
trick
is
a
job,
it's
a
component
called
lighthouse
and
that
uses
a
dot
lighthouse
folder,
where
you
can
actually
put
your
pipelines
and
resources
and
everything
you
need
inside
there
and
they're
kind
of
lightly
manipulated
and
then
applied
so
that
you
have
full
control.
I
was
wondering
whether
that
would
be
something
we
could
look
at
to.
C
B
C
I
don't
know
much
about
thanksgiving,
like
the
you
put
a
dot,
tecton
folder
in
the
root
of
your
gate,
and
then
it
basically
picks
everything
up
from
there.
So
I'm
not
very
sure
like
how
it
does
it.
But
it's
supposed
to
be
similar
to,
like
you
know,
having
a
travis
dot,
travis
folder
or
like
all
file
like
it's
supposed
to
be
similar
like
similar
to
that.
C
Okay,
I'm
actually
not
very
well
versed
with
jenkins
x,
apart
from
the
fact
that
it
uses
tecton
and
it's
like
an
amalgamation
of
different
components
like
which
work
together,
yeah.
But
but
I
understand
from
what
I
understood
you,
you
tried
to
run
jenkins
shops
through
techton,
and
you
would.
You
have
to
sometimes
spin
up
agents
by
yourself
that
that's
what
you're
avoiding
to
do
and.
B
Yeah,
so
they,
I
suppose,
the
initial
kind
of
prototypes
that
I
came
up
with
just
they
used
the
like
the
tecton
cli,
the
the
tkn
client
really
and
the
way
that
that
seems
to
work
is
it.
If
I
put
that,
if
I
put
the
control
of
that
into
a
pipeline,
then
I
end
up
with
a
an
agent
being
spawned.
I
suppose.
C
Jenkins
monster:
yeah:
okay,
okay,
okay,
so
so
how
you
so
are
you?
Let
me
let
me
go
back
to
another
question,
maybe,
which
was
repeated
so
cara
asked
a
question
about
if
we
can
run
these
run
the
client
without
a
jlp
like
an
environment
which
doesn't
need
a
chain
nlp
connection,
so
this
is
something
you
want
to
achieve
right.
C
B
B
B
And
at
least
monitor
it
for
for
failures,
I'd
like
understand
whether
or
not
it
fail
passes
and
fails
and
the
the
kind
of
like
ending
up
status.
You
know
it
affects
the
jenkins
job,
so
if
it,
you
know-
and
I
suppose
view
the
logs
of
that
pipeline,
as
I
would
through
the
ui-
that's
kind
of
where
I'm
thinking
that
would
be
like
kind
of
like
a
first
step.
C
Okay
and
then
it's
currently
the
sorry
sorry
for
breaking,
but
currently
the
the
logs
are
supported,
like
I
I
don't
know
so.
Last
few
times
I
prototyped
it
and
checked
it
for
like
for
cdcon
and
a
little
bit
after
the
the
log
streaming
worked
well
lock
streaming
works
well
for
task
runs,
I'm
not
sure
about
pipeline
runs
right
now.
I
need
to
check
it's
just
been
like
a
lot
of
time.
Since
I've
worked
last
time.
C
B
B
C
I
hope
to
start
working
properly
on
it
by
the
end
of
like,
at
least
by
the
end
of
this
month.
So
there's
a
there's
a
lot
of
stuff
and
like
help
would
be
appreciated
like
from
wherever
I
could
get.
I
am
trying
to
see
if
this
can.
I
I
don't
know
if
that's
possible.
Maybe
this
can
become
a
gsoc
project.
C
C
C
B
I
so
I
was.
I
was
working
on
jenkins
x
up
until
probably
about
midway
through,
oh,
maybe,
like
september.
I
think
it
was
yeah.
I
was
primarily
focused
on
drinking
sex,
but
working
on
like
sas
style
components
for
jenkins
x,
really
and
that's
where
we
were
focusing
on
and
then
since
then
we
have
been
I've
been.
I
joined
the
jenkins
community
team,
so
I've
been
looking
at
jenkins
sort
of
infrastructure.
B
So
the
main
the
instances
of
jenkins
that
host
we'll
build
all
of
the
plugins
do
with
what
we
do
releases
from.
So
it's
more
of
the
community
side
and
it's
all
it's
all
jenkins,
rather
than
jenkins
x.
But
what
I'd
quite
like
to
see
is
to
see
to
bring
it
over
some
of
the
learnings
from
jenkins
x
in
back
into
jenkins,
so
certainly
around
the
usage
of
techton
and
like
yeah,
better
ways
of
scheduling,
builds
and
pipelines
on
top
of
kubernetes.
C
Okay,
that's
good!
That's!
Actually,
that's
actually
very
nice
to
hear
because
you
like,
I,
I
don't
have
much
jenkins
experience
as
such,
but
like
we,
if,
if
we
are
able
to
work
together
and
work
on
something
that
will
actually
make
jenkins
support,
techton
and
maybe
anything
that
supports
flower
events,
I'm
just
like
looking
forward
to
that
really
cool.
B
And
what
I
think
there
would
also
be
other
people
in
the
community
interested
in
doing
this.
I
I
know
that
I've
spoken
to
like
a
few
ex-cloud,
these
employees
that
are
doing
or
running
into
the
same
sort
of
thing
problems,
and
they
really
want
to
know
how
to
get
much
better,
build
density
on
top
of
kubernetes
and
and
using
things
like
tekton,
and
can
they
sort
of
hook
it
all
together,
you
may
be
able
to
rope
other
people
in.
C
Yeah,
that
should
be
good.
The
thing
with
jenkins
is
I'm
going
to
be
extremely
blunt
here.
People
don't
like
the
fact
that
it's
a
monolith
and
it's
really
they
don't
like
the
fact
that
and
it's
not
about
even
liking.
The
performance
issues
are
there
and
we
have
a
lot
of
peeps
and
jenkins
in
open
shift.
Who
who
like
just
don't
like
it.
That's
why,
like
we
are
kind
of
moving
to
tecton
in
the
first
place
as
a
as
our
primary
say,
cd,
but
the
thing
is
the
matter.
C
C
You
should
you
can
do
that
with
like
some
some
integration
like
this,
so
I
I
really,
I
really
feel
it's
it's
possible
to
do
it
with
some
kind
of
plug-in
integration
or
something
so
so
I
I
look
forward
to
this.
Are
you
so
have
you
have?
You
run
run
the
plug-in
before
and
are
there
any
kind
of
issues
you
you
see.
B
C
B
A
So
this
is
the
tecton
client
plug-in
that's
available
on
the
experimental
channel,
okay,
two
things,
starting
with
the
more
important
one
for
for
moving
this
forward
at
a
community
level.
I
think
it
would,
you
know,
be
like
you
mentioned,
having
this
as
a
gsoc
project.
I
think
this
actually
would
be
a
fantastic
gsaf
project
and
would
either
of
you
like
to
to
do
a
draft
proposal
and
submit
it
on
the
mailing
list
for
you
suck.
A
A
A
C
A
C
So
I
actually
worked
on
the
jenkins
file
runner,
so
I
was
just
like
very
interested
with
the
jenkins
file
runner,
because
the
fact
that
you
can
run
jenkins
files,
like
oleg,
is
amazing
to
like
like
make
that.
I
I
really
like
the
jenkins
fire.
No,
no,
the
fact
that
you
can
run
jenkins
fires
on
a
serverless
fashion.
This
has
a
like
jenkins
x,
uses
tecton.
It
really
doesn't
run
jenkins
files
as
such,
but
jenkins
file
runner
actually
runs
jenkins
files
in
serverless
fashion.
C
So
initially
I
thought
that
jenkins
x
was
was
doing
something
like
that
when
I,
when
I
just
heard
its
name
but
later
on,
I
figured
out
that
it's
basically
running
technology
but
jenkins,
so
so
with
jenkins
file
runner,
if
you
can
just
give
jenkins
files
on
the
required
resources
in
a
fashion
which
is
replicable
and
like
I
was
thinking.
If
this
is
possible,
then
people
can
just
use,
use
this
methodology
to
run
their
jenkins
files
in
a
serverless
fashion.
C
To
do
this,
I
figured
out
this
sounds
like
a
great
idea
for
an
operator,
because
that's
what
operators
do
the
operators
are
used
to
like
replicate
like
replicate?
These
kind
of
you
know
processes
and,
though
so
what
the
operator
does
is
it.
It
basically
helps
the
user.
So
it's
even
that
is
like
in
a
poc
phase,
it's
not
in
the
jenkins
cia
or
girl.
So
it's
basically
just
poc,
but
it's
basically
just
supposed
to
allow
help.
C
Users
build
their
own
jenkins
file,
runner
image
and
that
image
will
contain
all
the
plugins
that
they
require,
and
then
they
can
use
this
image
against
any
jenkins
files
file
they
want
which
requires
these
plugins.
So
it's
it's
a
portable
image
which
they
will
be
keep
using
for
the
same
jenkins
files.
They
would
want
to
run
in
production
and
there
are,
there
are
a
few
things
missing
like
you
know
the
the
ability
to
add
our
back
or
to
the
jenkins
file
runner
pod.
C
So
once
that
our
back
is
given
that
the
the
the
operator,
the
quad,
can
actually
spin
up
other
pods
and
stuff,
because
when
you're
running
kubernetes
client,
the
kubernetes
client
require
in
in
the
kubernetes
client
plugin,
that
plug-in
requires
you
to
give
certain
permissions
to
the
pod.
So
we
did.
We
did
a
poc
on
this,
so
my
teammate
akram
he
had
actually
walked
on
the
jenkins
file
runner
to
do
a
poc
on
openshift
and
he
basically
ideated
that-
and
I
built
on
top
of
order
like
oleg
and
akram
built.
C
C
B
So
I
suppose
the
build
density
is
just
it's
referring
to
like
that.
The
number
of
the
number
of
builds
that
you
can
process
per
yeah
available,
cpu
and
memory.
So
on
kubernetes.
If,
if
we
say
we're
on
gcp
and
we're
running
with,
you
know
a
number
of
standard
size
nodes
or
something
like
that,
how
many
builds
can
I
actually
process
one
of
the
issues
that
we
had
on
jenkins
x
when
we
used
jenkins
file.
B
Runner
originally
was
that
because
it
requires
a
jvm
to
do
the
initial
launching
you're
if
you're
doing
a
maven
build
you're,
actually
launching
double
you're,
launching
two
virtual
machines
to
be
able
to
do
that
or
two
jdms
anyway,
to
be
able
to
do
that,
rather
than
with
tekton
you're,
just
launching
the
single
one
yeah
so
that
we
we,
we
had
to
run
with
pretty
much
double
the
number
of
nodes
to
process
the
same
amount
of
builds
using
jenkins
and
jenkins
file.
Runner.
C
The
jenkins
file
runner
is,
it
does
take
long,
though
images
do
take
a
long
time
to
build
actually
for
these
anchors
because
they
are
quite
heavy
and
like
tecton.
Even
the
core
tecton
doesn't
take
that
much
time
to
even
get
deployed,
but
the
jenkins
fire
runner
is
like
performance
heavy.
I
feel
that
way.
C
The
build
density
that
you
could
achieve
with
tecton
client
plugin
even
right
now
would
be
much
higher
than
actually
just
running
jobs,
because
at
the
end
of
the
day
it
is
using
tecton
and
if
you
consider
tecton
plant
plug-in
as
the
main
engine
for
your
jobs
through
jenkins
it.
It
would
not
engine
engines
the
wrong
word,
but
the
interface
for
your,
like
tecton
jobs
through
jenkins,
it
it
it
could
be.
You
could
achieve
a
higher
build
density
than.
C
I
would
say
it's
definitely
better
to
migrate
like
migrate
to
tecton.
So
currently,
I'm
working
with
the
guy,
like
he
he's
kind
of
a
he's.
I've
known
him
for
a
long
time
and
they
run
jenkins
in
their
like
environment,
and
he
he's
looking
at
moving
to
tecton.
So
he's
he's,
taking
my
help
to
like
understand
how
the
kubernetes,
like
kubernetes
side
of
things
works,
and
he
they're
just
saying
that
it
just
takes
a
lot
of
performance.
They
just
need
to
keep
like
upgrading
their
aws
instances.
Add
more
storage.
C
A
C
C
It
should
be
like
what
would
be
nice
is
when
like
when,
once
we
reached
a
dsl
stage
in
tecton
client
plugin.
At
that
point,
I
feel
users
would
be
extremely
comfortable
to
start
using
it
because
they
they,
I
I
feel
a
lot
of
them.
Maybe
don't
care
about.
You
know
some.
Some.
Some
of
them
might
not
even
care
about
the
ui,
but
a
lot
of
them
might
care
about
the
you
know
jenkins
file
itself
like
and
put
doing
everything
through
the
jenkins
file.
A
In
terms
of
what
prioritizing
work
you
mentioned,
that
cloud
events
would
facilitate
a
lot
of
the
tecton
plug-in
work
and
would
be
like
the
tatang
plug-in
would
have
a
hard
dependency
on
the
cloud
events
plug-in
is
that
is
that
still
the
the
development
like
basically
overall
roadmap
you're
looking
at
for
this?
That's
so
what
you're
thinking.
C
So
the
and
it's
it's
hard
dependency
dependency,
but
only
later
on,
like
you,
you
would
techn
might
use
some
of
the
plugins
capabilities
to
create
for
like
event,
listeners
and
stuff
so
to
create
an
event
listener.
Maybe
like
create
a
sink
like.
I
still
need
to
like
dive
deep
into
the
cloud
event
stuff.
I
I
have
tried
a
bit,
but
I
still
need
to
read
up
a
lot
more
about
it.
So
there's
a
lot
of
study
that
I
even
I
still
need
to
do
so.
A
I
think
I
put
a
link
on
your
draft
proposal
for
the
cloud
events
plugin
to
a
work
stream
group
with
the
continuous
delivery
foundation.
It's
under
the
interoperability
stake.
Actually
it's
going
to
become
its
own
say
probably
next
week,
but
that
might
yeah
that
might
be
an
interesting
meaning
or
sig
for
you
to
go
to
so.
A
C
I'm
actually
so
on,
I
guess
andrea
fritoli,
I
think
he's
part
of
the
workstream's
workstream
he
he
architected
the
cloud
events
stuff
in
tecton,
and
I
actually
want
to
I'm
actually
trying
to
study
that
the
way
he's
done
it
in
tecton
to
understand
how
it
could
be
may
be
replicated
for
jenkins
because
yeah.
For
me,
it's
just
a
learning
thing.
I
I
am
not
that
great
with
like
cloud
events
like
eventing
in
general,
but
I'm
just
trying
to
learn
as
well
as
time
goes.
C
A
A
C
A
Yeah,
it
would
be
really
nice,
maybe
maybe
we
can
get
all
again
he's
super
busy
right
now
he's
been
pulled
into
so
many
different
things
which
is,
but
I
know
he
likes
to
be
involved
in
the
community.
So
hopefully
this
is
a
meeting
that
will
interest
him.
Do
you
think
this?
This
is
a
good
meeting
to
continue
these
discussions
on
cloud
events
on
tech,
town,
catalog,
integration,
things
like
that.