►
From YouTube: Kubernetes WG Batch Weekly Meeting for 20220317
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
On
this,
okay
hi
everyone,
so
this
is
the
kubernetes
batch
working
group
weekly
meeting
this
meeting
will
be
recorded
uploaded
to
youtube.
Please
adhere
to
kubernetes
guidelines,
so
one
of
the
things
that
we
discussed
last
time
was
the
working
group
roadmap
and
we've
talked
about.
A
A
She
will
be
organizing
this
effort
with
regards
to
specialized
hardware
support,
so
she
already
have
the
you
know
the
topology
we're
scheduling
like
she's
collecting
information
about
that
and
the
other
two
issues
related
to
note
feature
discovery,
so
she'll
be
reaching
out
to
the
owners.
Try
to
establish.
A
You
know,
like
a
you
know,
proper
current
state
documented
so
that
we
can,
you
know
under
like
a
discuss
what
we
need
to
improve
in
that
work
scene.
Now,
on
on
our
side.
Last
last
week
we
discussed
mostly
the
job
management
we
wanted
to
do
something
similar
as
well
so
diane
and
and
aldo
they
created
a
a
template
for
presentations
for
existing
batch
schedulers.
A
So
the
starting
point
here
again
is
to
understand
what
existing
batch
scalers
that
were
built
on
top
of
kubernetes
are
doing
what
are
their
main
pain
points
and
then,
from
there
we
can
start
to.
You
know,
define
our
recommendations
for
enhancements
within
kubernetes
to
support
job
managers,
so
the
the
the
first
work
scene
with
regards
to
job
api.
I
think
they
kind
of
intersect
with
job
management,
but
I
feel
that
at
some
point
we
want
to
have
because
it's
a
large
scope,
like
we
have
three
things
that
we
want
to
talk
about,
etc.
A
Maybe
every
week
we
focus
on
only
one
and
try
to
make
progress
only
within
one
work
stream
in
in
some
capacity,
so
for
today
we're
not
going
to
talk
about
job
api,
although
we
have
some
comments
here
from
others
commenting
about
how
we
can
what
we
can
do
more
etc,
but
just
so
that
we're
focused,
we
will
be
talking
today
about
the
job
management.
We
have
our
first
guest
from
techtone
and
I
want
to
give
it
to
diane
or
aldo.
A
If,
if
you
want
to
present
and
discuss
the
template
quickly,
just
set
expectations
of
what
we're
trying
to
you
know
get
from
these
presentations.
B
Sure
I
can
just
do
a
talk
say
something
quickly
and
verbally.
You
don't
have
to
show
the
template,
but
the
whole
goal
that
we
aldo-
and
I
have
been
working
on-
is
really
just
to
try
to
get
a
good
grasp
on
the
challenges
that
these
solutions
have
provided.
B
That
they've
been
the
challenges
they've
had
to
overcome
with
regards
to
requirements
and
able
to
map
those
into
the
kubernetes
resources.
So
we
put
together
just
a
simple
template
to
try
to
hone
in
on.
You
know
how
we
might
understand
at
a
high
level
and
some
detail
the
the
patterns
that
were
being
used.
What
were
the
gaps
that
they
were
trying
to
accomplish?
B
You
know
what
are
the
workload
requirements
that
weren't
able
they
weren't
able
to
solve,
with
the
kubernetes
core
components
and
just
some
insight
on
how
they
did
some
deployments,
how
they
do
their
deployments
and
their
workflows.
B
So
it's
really
intended
to
truly
try
to
gather
you
know
these
high
level
patterns
so
that
we
can,
you
know,
take
them
all
and
find
out
what
we
can
extract
to
start
to
focus
in
on
this
work.
A
Thank
you
there,
and
so
I
like
what
we
get
if
someone
can
take
notes,
I
like
I
can't
take
notes
as
well,
but
if
someone
else
is
interested
in
taking
notes
for
the
tickton
presentation,
that
would
be
great.
C
I
can
try
that
in
the
same
dock,
as
you
have
separate
one.
D
I
would
keep
it
in
in
the
main
agenda
doc.
Yeah,
there's
no
reason
that
we
have
to
keep
another
one.
It
will
be
good
to
reference
if
you
want
to
have
a
high
level
overview
I'll
help
with
that
one
as
well.
So
the
two.
C
D
C
One
more
thing
I
wanted
to
say
about
the
template.
So
of
course
it's
not
set
in
stone.
It's
just
a
reference.
C
A
Sounds
good,
let
me
make
jason.
E
Maybe
yes,
this
seems
to
be
working.
E
Are
folks
able
to
see
that,
yes,
okay,
excellent,
you
see
tekton,
you
see
a
big
robo
kitty,
all
right,
excellent
yeah.
First
of
all,
thank
you
for
for
for
the
outline
for
the
for
the
template.
That
was
very
helpful
when
putting
this
together
to
know
you
know
sort
of
the
things
you
all
were
interested
in
hearing
I'm
going
to
not
include
a
lot
of
stuff
about
tecton
in
this
and
focus
on
the
stuff
that
I
think
is
most
useful
to
to
this
audience.
E
I
also,
I
think,
we'll
have
tons
of
time
for
questions
and
everything,
and
I
saw
that
vincent
and
andrea
are
also
here,
potentially
others
from
the
tecton
community.
So
if
we
have
time
for
questions
there
will
be
not
just
me
to
to
help
answer
them,
which
will
be
good
all
right.
Well,
yeah
thanks
thanks
for
having
me,
my
name
is
jason
hall.
I
work
at
red
hat
and
this
is
a
presentation
and
overview
of
tecton.
E
So
tekton
is
a
cicd
workflow
engine,
oh
god,
I've
clicked
a
button,
and
now
I
don't
know
how
to
stop
it.
Okay,
a
ci
cd
workflow
engine
on
top
of
kubernetes.
It's
based
around
ephemeral,
build
containers.
This
prevents
a
lot
of
supply
chain
attacks.
E
Things
like
solar
winds
and
things
like
other
build
systems
before
tecton
you'd
have
long-running
build
agents
that
wait
for
jobs,
and
then
you
know
do
some
stuff
and
those
long-running
persistent
workloads
meant
that
if
you
infected
or
compromised
or
did
something
to
that
long-running
workflow
or
that
that
long-running
build
agent
that
you
could
infect
future
builds
and
that's
roughly
at
a
very
high
level.
What
happened
with
solar
winds
and
there
have
been
a
number
of
similar
attacks.
E
Tekton
is
not
that
techton
just
aims
to
be
very
ephemeral
in
its
build
process
and
also
aims
to
like
one
of
the
value
propositions
of
tecton
is
that
you
can
secure
your
build
pipeline.
Your
build
cluster
using
the
same
tools
and
experience
and
knowledge
and
operational
knowledge
as
your
prod
cluster,
so
you're
using
kubernetes.
You
know
how
to
lock
down
permissions.
You
know
how
to
lock
down
our
back.
You
know
how
to
observe
things
and
watch
for
threats,
because
you
run
these
in
production.
E
You
can
also
use
that
to
maintain
you
know
and
observe
and
operate
and
extend
your
your
build.
Cluster
tekton
is
very
cicd
focused.
It's
it's
not
probably
going
to
be
as
focused
on
raw
throughput
as
a
lot
of
the
stuff
that
that
a
lot
of
the
other
projects
that
this
working
group
will
probably
talk
about,
and
it's
more
interested
in
isolation
and
flexibility.
E
So,
when
we're
talking
about
what
workload
we're
running,
we're
not
like
taking,
you
know
taking
a
string
and
basics
defouring
it
and
passing
it
along
the
pipeline.
We
are
like
compiling
code,
and
some
compilers
are
very
good
and
very
you
know,
secure
and
very
knowledgeable
about
boundaries,
and
some
just
have
no
problem
putting
files
every
damn
where
and
you
know
like
assume
that
they
completely
control
the
environment,
and
so
we
need
to
account
for
both
the
like
very
well-mannered
ones
and
the
very
non-well-mannered
ones,
and
that's
just
like
build
like.
E
Even
on
top
of
that
deployment
processes,
you
know
golden
file.
Generation
processes
are
completely
open-ended
and
users
can
and
will
do
whatever
they
want.
So
we
don't
focus
as
much
on
throughput
as
many
of
the
things
you'll
probably
talk
about
in
this
group,
but
we
are
very
interested
in
isolation
and
flexibility.
Pods
are
never
reused.
We
spin
up
a
pod,
we
run
your
build,
we
delete
it,
it's
never.
It's
never
going
to
be
used
for
another
workload
ever
again
and
templating
is
also.
E
To
us
for
for
usability,
for
the
ability
to
make
this
flexible
and
and
powerful
techton
is
a
cdf
founding
project.
We
were
founded
three
and
a
half
four
years
ago.
Even
that's
quasi,
a
number
of
products
and
services
are
built
on
top
of
tecton,
like
like
as
another
layer
on
top
of
kubernetes,
where
they
build
their
own
service
or
product
or
project
jenkins
x
is
one
of
these.
Shipwright
is
one
of
these.
E
Some
some
products
are
are
literally,
you
know,
a
distribution
of
tecton,
released
and
and
supported
with
with
some
features.
Openshift
pipelines
is
one
of
these
cloud.
Build
hybrid
work.
Worker
pools
is
a
service
that
google
is
working
on
to
do.
This
kubeflow
has
work
that
runs
kubeflow
pipelines
on
top
of
tecton.
So
it's
it's
both
a
thing
you
can
use
directly
and
a
thing
you
can
scaffold
build
on
top
of
other
services.
E
Other
products,
and
also
I
want
to
point
out
tekton,
runs
on
kubernetes
and
very
often
deploys
to
kubernetes,
but
it
doesn't
have
to
based
on
bug
reports.
We've
gotten
people
use
this
to
build
and
test
mobile
apps
to
build
game
engines
to
build
all
kinds
of
stuff
that
has
nothing
to
do
with
kubernetes
at
the
end
of
the
day,
but
being
able
to
isolate
and
operate
your
build
cluster
on
kubernetes
is
really
useful,
so
wherever
it's
being
deployed
to
having
having
it
run
on
kubernetes
is
really
nice.
E
A
brief
overview
about
the
architecture.
First,
we'll
talk
about
the
api
that
users
interact
with
the
you.
We
can
either.
E
Or
bottom
up,
this
is
more
of
a
bottom-up
approach.
People
tell
me
both
ways
are
good.
The
the
main
core
bottom
thing
that
we
run
are
called
task
runs
task
runs,
have
steps
which
are
defined
as
containers
that
execute
sequentially
in
order
that's
redundant,
execute
sequentially,
that's
also
a
typo
excellent.
E
This
is
literally
using
the
same
container
spec,
more
or
less
as
what
you
see
in
a
pod.
What
you
see
in
in
you
know
in
in
regular
kubernetes
those
steps
have
a
workspace
volume
attached
to
all
the
steps
by
default.
You
can
attach
other
volumes
if
you
need
to
share
other
data
between
the
two,
but
but
basically,
if
you
write
something
to
slash
workspace,
foo
in
step
one,
you
can
read
it
in
step
two
by
default,
we
have
a
notion
of
results.
E
If
you
write
data
to
this
magical
path,
tekton
results,
foo
tekton
will
collect
that
data
and
surface
it
in
the
api
and
parameters
as
templatized
inputs.
To
these
things,
you
can
also
pass
results
from
previous
task
runs
into
inputs
in
other
task
runs.
We
also
support
side
cars,
so
I
said
said
before
steps
run
in
order,
but
you
can
also
say
run
these.
E
You
know
run
these
three
containers
for
the
lifetime
of
the
task
run
alongside
those
are
useful
for
things
like
services
you
want
to
test
or,
if
you're
pushing
to
a
docker
registry
that
you
just
want
to
like
have
for
the
lifetime
of
that
pod.
That's
an
option,
so
task
runs,
run
everything
sequentially
in
order
and
are
pretty
self-contained
pipeline
runs.
Are
the
next
level
above
that
and
are
a
collection
of
task,
runs
that
execute
in
a
in
a
dag
in
a
directed
acyclic
graph.
E
So
this
is
where
one
pipeline
one
text,
one
task
runs:
results
can
be
passed
into.
Another
task
run
as
an
input,
and
then
you
can
stitch
them
together
and
you
can
say,
like
you
know,
these
five
task
runs
all
depend
on
this
input,
so
they
will
wait
until
the
first
one
finishes
and
when
that
one
finishes,
those
five
task
runs,
will
kick
off
and
start
and
do
whatever
they
want.
E
So
there's
fan
out,
there's
fan
in
there's,
I'm
not
going
to
go
much
into
it,
but
there's
conditional
execution
task
runs
and
pipelines
pipeline
runs
can
be
cancelled,
they
can
have
timeouts,
you
can
attach
other
workspaces
other
volumes,
I'm
probably
missing
a
ton.
We've
talked
before
about
having
task
run.
Steps
also
executed
in
a
dag
right
now
like
they
are
only
sequential
and
and
concurrency
comes
from
the
pipeline
run.
We've
talked
about
having
task
run,
steps
being
a
dag.
E
I
don't
know
if
that's
if
that's
really
gonna
happen,
but
we'll
see
and
the
last
one
is
tasks
and
pipelines.
So
I
mentioned
earlier
that
we're
very
interested
in
making
these
templatizable
task
run.
When
you
create
a
task
run,
it
starts
running,
it
starts
doing
something,
but
you
can
create
a
task
which
is
sort
of
an
inert
template
for
a
task
run
and
say
this
task
represents
fetch
a
git
repo.
E
E
We
have
a
catalog
and
a
hub
ui
to
share
common
task
definitions.
These
things,
like
fetch,
a
git
repo,
is
very
common
and
build
a
container
image
is
very
common,
so
those
those
are
shared
resources
that
you
can
sort
of
pull
off
the
shelf.
These
are
the
shelves,
I'm
also
not
going
to
go
into
a
ton
of
other
stuff
unrelated
to
this
I
mean
tekton's
a
huge
topic,
but
there's
there's
tecton
triggers
which
let
you
translate
incoming
web
hook.
E
Requests
from,
like
you
know,
from
your
github
integration,
also
that
that
has
like
native
eventing
compatibility.
If
you
want
that
techton
chains
is
a,
is
a
new
project,
relatively
new
project,
to
produce
a
bunch
of
supply
chain
artifacts
for
downstream
consumers.
E
E
Yeah,
like
I
said
before,
the
the
the
implementation,
the
actual
like
moving
parts
inside
of
tecton
pipelines,
is
the
the
task
run.
When
you
create
a
task
run,
we
well,
we
validate
it
and
then
we
translate
it
to
a
pod.
E
A
lot
of
the
pod
specifics
are,
you
know,
leaked
through
the
api,
so
you
can,
you
can
set
node
selectors,
you
can
define
node
affinity.
You
can
select
a
custom
scheduler,
the
same
way
that
you
can
for
a
pod.
We
don't
do
anything,
we
don't
tecton
doesn't
come
with
a
custom.
Scheduler
we've
talked
about
it,
but
I
don't
think
it
was
really
worth
the
the
maintenance
burden
to
do
that.
So
we
just
rely
on
the
regular
kubernetes
scheduler.
E
We
have
a
controller
that
watches
the
pods.
We
create
and
updates
the
task
run
status
to
say,
like
you're,
on
step,
305
and
now
you're
on
step,
four
or
five.
Oh,
it
failed.
You
know
things
like
that.
Steps
are
sequentialized
by
injecting
an
entry
point
binary,
which
is
probably
the
largest
hack.
I've
ever
been
proud
of
steps
aren't
dynamic.
So
you
can't
a
step
three
can't
say
there
are
three
more
steps
like
you
know,
like
they're,
you
know,
add
three
more
steps
to
the
end
of
this
workflow
there.
E
You
say
these
are
the
five
steps
to
run
and
they
run
them.
Results
are
surfaced
when
you
remember
when
I
said
like.
If
you
write
to
techton
results,
foo
it
magically
gets
bubbled
up.
That
magic
is
powered
by
termination
message
pads,
which
is
maybe
the
second
biggest
hack
I've
ever
been
proud
of.
But
that's
that's
really
nearly
going
to
go
away
because
we
we
really
need
to
be
off
of
that
termination
message.
Paths
are
very,
very
limited.
E
You
are
limited
to
four
kilobytes
per
container
and
12
kilobytes
total
per
pod,
which
is
not
a
lot
of
data
to
exfiltrate.
From
your
from
your
build
system,
we're
exploring
a
lot
of
our
alternatives.
We
have
some
ideas,
but
yeah.
We
that's
sort
of
the
a
big
thing
we
need
to
fix.
The
pipeline
run.
Controller
does
does
sort
of
kind
of
what
I
mentioned
before
it
watches
for
task
run
statuses
when
it,
when
one
task
run
in
the
pipeline
run
finishes,
it
says,
did
anything
depend
on
this.
E
A
E
A
E
Yeah,
so
each
task
I
I
should
have
presented
a
snippet
of
like
what
a
task
run.
Yaml
looks
like,
but
basically
there's
a
steps
array,
a
step
slice
of
containers
and
it
runs
the
first
one
and
when
the
first
one's
done
it
runs
the
second
one
and
etc,
and
you
can
you
can
set.
There
is
also
a
pod
template
support
for
things
like
the
node,
selectors
and
node
affinity
and
scheduling
stuff
like
that
and
service
account
name,
and
you
know
all
the
the
usual
the
usual
suspects.
E
There's
two
that
one
of
the
things
in
the
in
the
template,
which
I
thought
was
useful,
was
the
like
administration
workflow,
you
can,
you
can
install
tekton
just
by
applying
this
one.
You
know
large
generated
yaml.
E
We
also
have
an
operator
which
you
can
install
it
among
many
many
other
things
like
setting
a
lot
of
config
stuff.
It
also
lets
you
control
pruning
and
object
retention,
so
each
task
run
that
executes
is
an
object
that
we
store
in
fcv
that
we
reconcile
until
it's
done
and
by
default
those
don't
go
away.
So
you
can
imagine
over
months
and
years
you
just
accumulate
thousands.
Tens
of
thousands,
hundreds
of
thousands
and
oops
fcd
just
exploded
in
your
face
and
took
down
the
rest
of
the
cluster
too,
which
is
really
exciting.
E
So
the
operator
is
also
responsible
for
you
can
configure,
you
know,
keep
only
the
last
week's
worth
of
task
run
and
pipeline
runs
or
keep
only
the
last
hundred
of
those
objects
or
whatever
all
of
the
images
that
come
in
operator
and
in
the
in
the
release
are
signed.
E
E
Like
start
this
task
run,
or
I
guess
it's
a
task.net
anyway
start
this
task
and
you
can
pass
parameters
and
tkn
task
logs
is
really
useful
because
it
sort
of
shortcuts
the
annoying
gymnastics
of
find
the
pod
for
this
task
run.
E
Okay,
now
get
logs
for
that
pod
and,
like
I
always
forget,
to
do
dash
dash
all
containers
and
then
there's
like
a
dash
dash
max
container
limit
equals
100,
whatever
tcan
task
logs
takes
care
of
that,
for
you
there's
also
tkn
pipeline
logs,
which
is
even
more
interesting
because
it
does
that
across
many
potentially
concurrent
tasks,
all
at
once
and
interleaves
them
together.
E
E
For
operations
we
have,
we
have
basically
two
components
that
we
install
in
the
cluster
that
yaml,
that
you
install
sets
up
a
bunch
of
bar
back
and
create
stuff
and
then
basically
just
creates
two
deployments.
One
is
the
controller
deployment,
it
watches
all
tecton
resources,
it's
responsible
for
creating
pods
and
watching
those
pods
for
pipeline
runs
it's
responsible
for
creating
those
task
runs
and
watching
those
task
runs
and
updating
statuses
by
default.
It's
it's.
E
I
think
in
that
yaml
it's
replicas
one,
but
we
do
support
leader
election
and
started
work
queues
if
you
want
a
a
more
disaster
resilient
controller.
E
If
that
controller
is
down
running
workload,
pods
will
still
run
right,
like
the
the
controller
is
not
in
constant
contact
with
the
pod,
it
starts.
It
just
shoots
a
pod
into
the
api
server
and
then
is
responsible
for
watching
it
and
updating
the
test
run.
So
if
the
controller
is
down
for
any
reason,
your
work
is
still
running,
but
you
may
not
see
the
updates
for
it.
E
So
short,
outages
are
invisible
to
you,
but
longer
outages
might
be
bad.
We
also
run
a
validation
web
hook.
We
do
a
ton
of
validation,
an
absolute
ton
of
validation,
for
instance,
when
you
give
us
a
pipeline
run,
we
have
to
validate
that.
It
actually
represents
a
dac
so
like
here,
are
there
any
cycles
in
the
in
the
set
of
tasks
you've?
E
Given
us
and
a
ton
of
other
stuff,
we
have
a
lot
of
defaulting
configured
using
a
config
map
we
convert
between
the
many
api
versions
and
that
webhook
deployment
also
is
replicas
one,
but
it's
completely
stateless
and
can
auto
scale
easily.
If,
if
that's
something,
you
want
all
the
code,
based
on
like
historical
reasons,
all
the
code
in
tacton
is
very
heavily
based
on
k
native.
We
actually
came
from
k
native
years
and
years
ago,
which
is
actually
really
nice.
E
They
they
have
a
lot
of
facility
to
generate
informers
and
reconcile
reconcile
boilerplate,
reconciler
boilerplate,
the
container
images
for
the
controller
and
web
hook
and
a
bunch
of
other.
We
have
a
bunch
of
other
supporting
containers
that
run
inside
those
workload
pods.
Those
are
all
built
using
a
tool
called
co.
The
workload
pods
can
even
run
inside
of
windows,
which
is,
I
think,
relatively
unique
among
kubernetes
workflow
things.
E
I
don't
know
if
that
we
can
go
into
more
detail
about
whether
that's
needed
or
anything
for
everybody
else,
but
I
think
that's
an
interesting
thing
at
least
kubernetes
gaps.
These
are
a
short
list,
but
basically
real
you
know.
Official
actual
support
for
sequentially
running
containers
would
be
excellent.
I
think
probably
90
of
the
code.
Well,
that's
high.
E
At
least
a
good
30
of
our
code
could
go
away
if
we
could
just
tell
a
pod
to
run
a
and
then
b
and
then
c,
so
it
is
more
complicated
than
that
like
we,
we
used
to
be
on
init
containers
which
do
run
sequentially,
but
that
was
not
a
very
good
fit
and
it
did
not
last
very
long.
E
One
reason
is:
we
also
do
want
those
sidebar
containers,
so
it's
not
as
easy
as
a
and
b
and
c
it's
start
a
keep,
a
running
run
b,
then
c
then
kill
a
or
you
know,
etc.
That's
a
that's
a
bit
harder
to
express
in
a
yama-like
language.
E
These
these
containers
also
support
timeout
and
cancellation,
so
like
run
a
for
no
more
than
10
minutes
and
then
kill
it
or
run
a,
but
if
the
user
says
stop
it
stop
it.
You
know
relatively
immediately
is
also
not
something
that's
very
easy
to
describe
in
a
declarative,
kubernetes
animal
and
the
results.
Collection
is
also
another
thing.
We'd
still
have
to
have
some
way
to
collect
the
stuff
people
write
to
these
magical
paths.
E
Ephemeral
containers
are
a
thing
that
people
sometimes
bring
up.
I
think
they're
not
a
very
good
fit
for
our
use
case
so
like,
but
at
a
high
level.
The
way
we
could
use
ephemeral
containers
is
to
say,
like
okay
step,
one
finished
create
an
ephemeral
container
for
step
two
and
then,
when
step
two
finishes,
create
an
ephemeral
container
for
step.
E
E
So
that
would
be
great,
but
we're
probably
going
to
have
to
get
off
of
that
anyway,
and
some
way
to
configure
automatic
pruning
of
oldest
resources,
either
per
type
like
for
the
task
run
type
in
this
cluster
and
never
let
there
be
more
than
ten
thousand
of
them
would
be
something
we
would
love
to
be
able
to
say.
There's
quotas
right,
there's,
there's
ways
to
say
like
don't.
Let
me
create
a
ten
thousand
in
first
one,
but
that's
not
a
great
experience
either.
We
want
someone
to
create
it,
but
we
want
someone
to.
E
We
want
something
to
go
and
delete
the
the
oldest
one
in
that
case,
so
I
don't
know
if
that's
a
feature
that
other
folks
on
the
caller
are
interested
in
exploring
more,
but
these
are
sort
of
our.
This
is
a
the
top
three
of
our
wish
list
of
kubernetes.
E
There's
a
lot
more
reading
and
more
viewing
techton.dev
has
all
of
our
documentation.
We
have
techtoncd.slack.com
if
you
want
to
come,
join
us
in
slack.
There
have
been
a
couple
of
talks,
especially
about
the
entry
point
injection
stuff
that
myself
and
christy
wilson,
another
maintainer
on
techton
gave
in
2019,
and
there
was
a
talk
in
last
year
with
alex
from
argo
workflows
about
some
of
the
common
stuff.
We
have
common
difficulties
and
common
solutions.
E
We've
had
between
argo
workflows
and
techcon,
and
if
you're
interested
more
in
that
windows
thing,
I
also
went
and
talked
to
the
kate's
sick
windows
in
like
november.
I
think
about
more
about
how
we
do
that,
but
otherwise
that's
all
I've
got.
We
have,
I
think,
a
ton
of
time
for
questions.
If,
if
you're
interested,
I
will
remind
you
that
andrea
and
vincent,
oh
they're,
even
in
the
chat,
excellent,
both
of
them
are
here
if
they
feel
like
answering
the
question
too,
that
that's
fine.
A
Thank
you
jason.
This
is
great.
I've
got
like
three
or
four
questions,
but
I
first
want
to
open
the
floor
for
the
community
to
ask
first.
F
So,
do
you
use
naked
ports
or
or
do
you
have
like
a
higher
level
workload
api
that
you
use
for
the
task
run
or
some
other
custom
resource
that
you
are
defining.
E
Many
users
don't
create
task,
runs
themselves,
many
users
just
create
pipelines
and
then
start
them
with
some
parameter
and
and
watch
the
pipeline
run.
That's
created
so
in
that
way,
like
yeah
task
runs,
are,
are
the
workload
abstraction
crd
that
we
have
around
pods,
but
there's
nothing
between
task
run
and
pod.
It
goes
straight
from
task
front
to
bottom.
E
Yeah,
so
we
were
on
jobs
for
a
while,
actually
very
early
on,
and
the
reason
we
didn't
want,
the
reason
we
didn't
go
for
that.
Actually,
I
don't
think
they
really
gave
us
a
lot
like
it
was
again.
These
are
like
create
one
thing
and
wait
for
it
to
finish.
E
There's
no,
there's
no
reusability
at
all,
there's
no
like
queue
that's
being
consumed
and
in
in
fact
also
it
exacerbated
our
xcd
problem
right,
where
every
every
task
run
created
a
job
which
created
a
single
pod,
and
now
we
have
double
the
amount
of
objects
in
in
fcd,
as
we
or
I
mean
50
more
objects
in
ftd,
as
we
used
to
have
so.
Instead,
if
we're
not
getting
anything
out
of
jobs,
we
just
create
them,
create
the
pods
ourselves.
E
E
There
are
none
today,
but
if
job
was
the
type
that
gained
the
sequential
step
feature
or
the
you
know,
some
timeout
feature
that
was
really
useful
or
some
you
know
proactive
cancellation
feature
we
might
consider
it.
I
do
think
it
would
have
to
be
pretty
big.
For
us,
like
fcd
contention,
is
a
large
issue
in
the
operation
of
tecton
clusters,
and
so
it
would
have
to
be
a
real
benefit
to
be
worth.
F
Yeah,
I
want
to
briefly
talk
about
that
using
the
database
correct,
but
I
think
we
can
talk
about
it
later
sure
yeah
that
that's
all
I
have
for
now
like
I.
I
just
want
to
know.
If
you
have
the
list
of
features
that
would
have
made
job
useful,
I
think
that
would
be
helpful.
E
Sure
yeah
I
can
offline,
I
can
go
dig
up
the
the
discussion
we
had
around,
that
I
mean
they're
they're
three-year-old
bugs
so
like
we
made
the
decision
a
very
long
time
ago
and
it's
possible
that
jobs
have
improved
enough
that
now
we
should
reconsider
it,
but
yeah
yeah.
B
E
No,
that's,
actually,
that's
actually
not
correct,
so
so
each
task
run
is
one
pod
right,
and
so,
when
you
say
step
one
is
you
know,
echo
foo
or
like
echo,
foo
pipe
to
some
file
or
redirect
to
some
file
what
we
take
that
intent
and
then
we
wrap
it
in
a
binary
that
we
control,
or
you
know,
a
process
that
we
control
and
say
actually
step.
One
is
execute
our
process
to
do
that.
Work.
E
That's
important
for
step,
one!
That's
not
very
exciting,
because
it's
just
gonna
like
start
and
do
the
work
for
step,
two,
that
that
process
is
responsible
for
watching
step,
one
to
finish,
watching
for
waiting
for
step,
one
to
finish
and
then
run
whatever
work.
It
does
and
then
kick
the
you
know
kick
the
can
down
to
other
steps.
E
So
in
fact
each
task
run
starts
one
pod.
All
the
containers
start
at
once
in
that
pod,
but
the
second
step
container
has
a
process
like
its
process
is
waiting
for
the
other
one.
To
finish,
you
know,
in
a
sequence,
I'm
not
sure
that
I
described
that
very
well,
but
yeah
we're
not
creating
a
pod
per
step.
We're
creating
a
pod
per
test
run.
D
E
A
lot
of
hacks
involved
in
getting
that
binary
to
correctly
wait
for
the
previous
step
to
finish
and
and
react
to
cancellation
or
react
to
timeouts
and
things
like
that.
E
We
override
the
entry
point
with
a
with
our
own
process
that
either,
if
it's
step
one
execute
immediately
and
then
signal
to
the
next
step,
and
if
it's
step,
two
wait
for
that
signal.
Do
some
do
your
work
and
signal
to
the
next
step,
et
cetera,
et
cetera?
The
2019
talk
vincent
mentioned
in
the
chat.
The
2018
talk
was
was
a
lot
about
this
there's
some
of
it
in
the
2021
talk,
but
the
2019
talk
really
goes
into
detail
about
it.
E
So
that
goes
back
to
the
controller
in
you
know
how
much
involvement
the
controller
has
to
have
in
the
workload
there's
a
few
reasons.
I
think
the
main
one
is
that
we
don't
want.
E
If
you
want
to
run
five
steps
and
the
controller
is
down,
you
want
to
still
be
able
to
execute
all
those
you
still
want
to
be
able
to
make.
You
know
useful
work
while
the
controller
is
unavailable
or
while
the
controller's
backed
up,
and
so
if
each
new
step
was
start
a
pod
and
and
when
it
finishes,
the
controller
will
see
that
that
pod
is
finished
and
start
the
second
one,
and
then
the
controller
will
see
that
one
finish
and
start
the
third
one.
E
That's
a
bit
too
much
interaction
with
the
controller
for
us
and
as
andrea's
saying
in
the
chat.
Spinning
up
a
pod
brings
a
lot
of
overhead,
especially
if
it's
very
common
that
that
two
steps
in
a
task
run
will
share
some.
You
know
volume
right
like
we'll
share
some
some
state
with
each
other,
and
so
that
means
that
pod
has
to
go.
E
If
there
were
two
pods
they'd
have
to
go
to
the
same,
node
they'd
have
to
use
like
either
a
hoster
directory
or
a
you
know,
some
sort
of
volume
to
share
data
between
them
as
vincent's
saying
now,
excellent,
and
so
really
like
for
a
lot
of
reasons.
Having
each
step
be
its
own
pod
was
was
not
feasible
for
us.
E
We've
talked
about
it,
we've
also
talked
about
being
able
to
suspend
a
a
task
run.
We
could
in
both
cases
right
like
we
could.
I
think
there
is
actually
a
paused
state
on
pipeline
runs
where
which
just
means
when
the
controller
sees
a
task
run
has
finished
before
it
starts
a
new
one.
It
will,
you
know,
check
if
it's
paused
and
if
it's
paused
don't
create
the
next
task,
run
until
it's
unpaused
and
then
it
will
go.
There
may
be
a
pause,
a
paused
state
in
the
in
the
pipeline
run.
E
I
don't
think
it's
very
widely
used,
or
at
least
not
in
my
own
personal
experience
or
in
the
my
experience
by
you,
know,
handling
bugs
for
stuff,
but
yeah
and
we've
talked
about
it
for
task
runs.
Also,
you
could
do
a
similar
thing
where,
after
step,
two,
the
the
entry
point
injected
binary
says.
Oh,
am
I
paused?
If
I'm
paused,
don't
start
the
next
one,
but
we
really
haven't
gone
into
it,
not
very
much.
D
E
Yeah,
so
we
have,
let
me
go
into
a
little
more
detail
about
what
it's
actually
doing.
So
what
we
need
to
do
is
for
the
workload
pod
to
be
able
to
write.
So
you
know
like
echo
hello
world
and
have
the
the
api
level
have
that
stored
in
scd
somewhere
right.
Have
the
controller
be
able
to
see
it
so
that
it
knows
what
to
pass
to
the
next
thing.
E
Termination
message
paths
are
very
good
for
this
because
you
literally
like
the
kublet,
will
collect
that
file
and
write
it
up
to
the
api
server
for
us.
But
again,
it's
very,
very,
very
limited.
E
We
have
explored
and
have,
I
think,
even
like
some
functionality
in
in
the
past,
for
storing
this
data
in
gcs
or
s3,
or
you
know
elsewhere
outside
that
turns
into
a
bit
of
a
a
latency
issue,
or
I
mean
like
or
a
reliability
issue,
because
it's
going
like
to
some
external
dependency
outside
of
the
cluster
and
also
like
an
extensibility
issue.
So
if
we
support
gcs
and
s3-
and
somebody
says
now-
I
want
you
to
support,
you
know
azure's
storage
service
and
my
own
homegrown
storage
service
like
it's
it.
E
I
fear
the
slippery
slope.
I
know
that's
a
slippery
slope
argument,
but
that
I
think
so
rather
than
have
specific
hard-coded
implementations
of
storage
for
this,
I
would
rather
have
something.
That's
extensible
where
we
say
it's
extensible
and
we
come
with
three
types
and
if
you
want
to
add
a
fourth,
you
can,
you
know,
follow,
implement
this
protocol
and
do
whatever
you
want.
I
think
that's
roughly
the
shape
we'll
have
for
what
the
replacement
for
this
is,
but
it's
it's
sort
of
in
the
middle
of
design
and
not
really
implementation.
Yet.
E
Thing
you
mentioned
was
a
a
pv
where
we
could
do
that,
but
that
doesn't
get
it
out
up
to
the
controller.
So
if
we
write
it
to
some
persistent
volume
that
that
hello
world
I
wrote
is,
is
stuck
in
a
pb
somewhere
and
either
something
has
to
read
that
pv
and
tell
the
controller
about
it.
Tell
the
api
server
about
it
or
the
controller
has
to
mount
that
pv
and
like
that
becomes.
Another
scheduling.
Bottleneck
for
everything
has
to
run
on
the
same
node
as
the
as
the
controller
or
the
pv
watcher
or
whatever.
E
E
Right,
we
actually
need,
if
yeah,
depending
on
how
how
we
would
design
it.
We
would
need
multiple
writers
and
one
reader
where
multiple
pods
on
multiple
nodes
could
write
to
it,
or
I
mean
some.
You
know
it's
possible
that
we
could
do
this
with
a
pv,
but
I
think
it's
not
going
to
be
any
easier.
Then
the
other
nice
thing
about
if
it
is
an
extensible
protocol,
if
there
is
some
some
extension
possibility,
one
of
the
implementations
could
be
pvs.
You
could
implement
the
protocol
using
just
local
pv
storage.
A
I
want
to
take
a
like.
I
mean
like
a
more
batch
related
question.
I
mean
all
of
those
all
of
this
is
like
it
is
batch
related,
but
it
seems
at
the
higher
level
like
with
in
the
concept
of
job
management
yeah.
Thank
you
for
bringing
up
the
job
api
and
and
how
we
can
better
improve
it
for,
for
techton
seems
to
me
that
you
want
the
task
current
to
represent
as
a
job
like.
A
Ideally,
you
would
want
to
not
have
a
task
run,
for
example,
crd
and
just
create
a
job
directly
and
be
able
to
express
those
there,
but
it
seems
that
it's
way
more
to
like
way
too
complicated
to
actually
make
it
generally
enough
to
push
it
down
to
have
it
as
a
kubernetes
core
feature.
You
do
a
lot
of
yeah.
E
Yeah,
I
definitely
I
definitely
would
not
would
not
advocate
for
a
kubernetes
core
task
run
like
a
lot
of
the
stuff.
We
do
is
bonkers
and
would
not
be
something
I
think
other
people
should
do
or.
D
E
You
know
people
should
use
tekton,
I'm
not
saying
people
shouldn't
use
techcon,
but
I
don't
think
it's
a
generally
applicable
thing
in
general,
but
if
they're,
if
some
of
these
things,
like
sequential
steps,
were,
were
a
feature
of
jobs
or
a
feature
of
pods
or
if
results
collection
was
something
that
existed
elsewhere,
we
could
still
wrap
that
in
task
runs
but
take
advantage.
You
know,
delete
a
lot
of
our
code
and
just
use
a
lot
of
kubernetes
core
functionality
for
that.
Okay,.
A
And
I
guess
we
can
follow
up
on
that
on
the
slides
to
perhaps
have
a
more
like.
You
know,
concrete
list
of
what
potential
things
we
can
do
to
the
job
api.
Maybe
you
will
not
use
it
yourself
like
a
tic
tone,
but
in
general
we
will
try
to
do
that.
The
other
thing
that
I
have
like
I
have
a
question
about
is
how
do
you
envision
this
being
integrated
with
like
job
queueing
in
general?
A
I
can't
use
more
than
x
resources
at
what
level
do
you
see
that
the
queuing
should
happen
seems
to
me
here,
for
example,
maybe
at
the
task
run
level,
it
could
also
happen
at
the
pipeline
level,
but
I
don't
know
if
we've
ever
been
faced
with
these
type
of
questions
or
or.
E
Setups
we've
we've
definitely
been
faced
with
the
question.
The
the
the
main
answer,
as
unsatisfying
as
it
is,
is
to
rely
on
existing
kubernetes
controls
for
for
either
pod
resource
constraints
in
a
namespace
where
you
say
like
this,
namespace
cannot
use
more
than
10
cpus
and
each
I
mean
that's
a
that's
a
coarse
hammer
to
to
solve
this
problem
with,
but
like
that
at
least
works
and
is
not
tecton's.
Responsibility
to
build
and
is
well
known
and
well
understood
elsewhere
and
the
other
one
is
is
resource
quotas.
E
So
never
let
someone
take
never
let
someone
create
more
than
10
pipeline
runs
and
the
11th
will
fail
or
something
vince
is
saying
in
the
chat.
We
do
take
into
account
limit
range
and
resource
quota,
but
it
has
a
lot
of
gotchas
and
limits
and-
and
you
know
quirks-
we
have
been
asked
in
general
if
there
is
some
way
to
to
have
concurrency
limits
on
pipeline
runs.
E
The
specific
a
specific
use
case
is,
if
you're,
if
you're,
using
tekton
hooked
up
to
your
github
repo,
you
may
never
want
to
run
two
pipelines
on
the
same,
commit
and
so
or
on
the
same
pr
or
whatever
at
the
same
time.
So
if
these
are
like
deploying
from
pr's
and
you
push
a
new
commit
to
the
pr
while
the
other
well,
the
previous
one
is
still
running,
you
may
want
to
cancel
it.
You
may
want
to
cue
it
behind
it.
E
E
Oh
because
there
is
a
paused
state
in
the
pipeline
run,
you
can
say
you
can
have
another
controller
watching
and
saying
you
know,
pause
this
control
pause
this
pipeline
run
until
this
other
pipeline
run
finishes,
or
you
know,
until
there
are
fewer
than
x
running
pipeline
runs,
it's
not
a
great
story.
I'm
not
going
to
try
to
tell
you
that
people
like
that
answer
when
we
give
it
to
them,
but
that's
that's
kind
of
the
best
answer
we
have.
A
So
we're
actually
building
something
like
that
and
and
that's
the
reason
for
my
question
is:
if
you
have
at
the
task
run
level,
you
think
this
is
probably
a
reasonable
unit
of
queuing
and
resource
management.
I
think
it
is
because,
like
when
you
create
a
pipeline
run,
you
don't
create
all
the
tasks.
That's
right!
You
only
create
them
when
you
need
them
right
right.
A
So
if
you
created
ascribe
and
that
task
run
gets
skewed,
your
pipeline
run
will
continue
to
wait
until
that
task
run
is
finished
right
and
if
that
task
run
is
suspended
and
not
executing
until
it
gets
its
resources
and
and
get
and
gets
like
you
know
and
finishes,
then
you
get
all
these
semantics.
Probably
correctly,
you
know
run
right
like
so.
A
E
Yeah,
I
think
I
think
that's
I'm
not
sure.
I
don't
remember
the
conversation
we
exactly
when
we
went
from
jobs
to
pods.
I'm
not
sure
whether
the
concurrency
limitation
issue
was
an
issue
back
then,
and
so
it's
possible
that
we
we
decided
that
it
was
worth
getting
off
of
jobs
to
go
to
pods
directly.
But
if,
if
that's
like
improvements
coming
to
jobs,
then
it
starts
to
change,
starts
to
change
our
calculus
on
whether
it's
worth
going
through
that
intermediary
to
pods.
Definitely.
A
E
I
don't
think
task
runs
currently
have
a
paused
status.
I
think
only
pipeline
runs
have
a
pause
status
and,
and
what
that
means
is
don't
create
the
next
task
run.
We
don't,
we
don't
create
any
sort
of
paused
pod.
We
will
just
the
pipeline
run.
Controller
just
won't,
create
a
task
run
until
until
it's
unpaused
right.
A
What
I'm
saying
is:
can
we
introduce
a
suspend
to
the
task
run
itself?
Let's
say
that,
basically,
the
task
current
controller
wouldn't
create
the
pod
until
it's
unsuspended
and
then
that
would
offer
us
that
integration
hook
to
cue
task
runs
and
do
resource
management
dynamically.
Rather
than
that
big
hammer
of
all,
you
have
to
continuously
create
the
pod
and
the
pocketing
rejected,
because
you
don't
have
cpu.
E
Yeah
right,
I
I
should
mention
also
when,
when
the
task
run
tries
to
create
the
pod,
if
that
fails,
it
will
continually
retry
creating
that
pod,
so
it
so,
it
will
look
like
the
task
run
is
queued
when
it
can't
create
a
pod
but
yeah
yeah
yeah,
but.
E
E
So
if
there's
any
knowledge
or
features
or
prospective
interest
in
these
things
among
folks,
I'm
definitely
interested
in
reaping
the
rewards
of
that
inside
of
texacon.
A
Yeah
I
mean
we
do
have
that
worksheet
on
job
management.
It
just
definitely
fits
within
that.
If
you
have
a
specific,
like
you
know,
I,
like
you,
know,
thoughts
on
what
is
missing
in
terms
of
like
you
know,
scheduling
what
we
can
introduce
downstream
or
upstream.
Please
add
them
to
the
roadmap
dock,
and-
and
this
is
all
interesting-
that's
for.
E
D
More
like
a
general
comment
about
the
pruning
resources,
which
was
your
last
complain.
Let's
call
it
that
way
to
cube
the
majority
of
the
controllers
that
we
have
in
in
cube.
They
implement
the
printing
with
them
themselves,
so
we
don't
have
a
general
mechanism
for
pruning,
but
cron
job
and
deployments
damon
says
stateful
sets.
There
are
usually
a
configuration
options
which
will
tell
oh
keep
this
many
old
yeah
resources
that
we
care
about
for
this,
depending
on
whether
they
failed
or
succeeded,
and
after
that
it
just
drops
them.
E
Yeah,
I
wonder
if
I
mean
that
that
makes
me
want
a
common
configuration
for
this
even
more
right.
If
every
new
crd
author
has
to
go
reinvent
that
api
and
reinvent
the
implementation
of
it,
that's
that's
not
going
to
be
very
scalable
but
yeah.
I
guess
that's
that's.
What
I
want
is
is
somebody
else
to
build
this
and
for
us
to
just
plug
into
it
using
the
common
semantics
common
api.
E
You
know
I
would
hate
to
do
the
same
thing,
but
call
it
prune
no
more
than
instead
of
like
whatever
the
approved.
If
there
is
a
single
approved
field,
name
or
whatever,
among
all
the
things
in
google.
F
Yeah
just
to
act
that
we
also
have
a
garbage
collector
running
as
a
controller
for
the
parts
or
the
objects
that
do
not
have
any
owner
references
so
yeah.
This
is
not
deterministic
enough.
E
I'm
not
sure
I
remember
off
the
top
of
my
head.
I
think
we
remove
the
owner
reference
for
it
and
make
it
an
unknown
pod,
and
then
it
goes
away.
I'm
not
sure.
E
Okay,
I
will,
I
will
go,
do
some
homework
and
figure
out
how
exactly
we
are
making
sure
that
the
pods
go
away,
but
right.
C
Yeah
the
reason
I
asked
that
is
because
in
job
we
had
issues
precisely
because
the
garbage
collection
collector
was
removing
the
pots.
So
that's
something
we
can
advise
on
but
yeah.
Ideally,
we
would
have
like
you
to
use
job,
but
so
you
don't
have
to
do
this
yourself,
but
we
yeah.
We
can
still
like
learn
from
your
use
case
and
casing.
A
Job
ap
has
a
couple
other
features
that
you
like.
It
has
ttl
to
finish,
which
is
basically
it's
pruning.
If
you're
using
the
job
api,
you
can
set
a
time
after
which
the
job
can
be
deleted
after
it.
A
E
A
So
that
that's
one
thing,
the
other
thing
it
has
active
deadline
seconds
which
is
like
timers
on
the
job
like
how
long
can
it
drop
like
can
be
active,
so
those.
E
When
let
me
ask
you
a
question
about
that,
when
the
deadline
is
exceeded,
does
it
delete
the
pod.
A
So
for
the
active
one
it
will
be
the
parts
the
job
will
exist
for
the
other
one,
the
ttl.
After
finish,
it's
basically
delete
the
job
object
and
which
means
all
or,
like
you
know,
parts
on
why
the
job
will
be
as
well.
E
Yeah
vincent
said
in
the
chat
we
also
set
active
deadline
seconds
on
the
pods
we
create,
but
it's
worth
noting
that
deleting
pods
tends
to
cause
the
logs
to
disappear
faster,
also-
and
so
that's
that's
also
a
ux.
Oh
man
there's
a
ton
of
work
on
reaping
these
logs
and
stuff,
but
for
cancellation
in
particular.
One
thing
we've
never
mind.
I
think
I
think
that's
not
even
true,
never
mind.
I
will.
I
will
stop
there
instead,
because
we're
over
time
anyway,
yeah.
A
A
Why
are
we
having
all
these
workflow?
You
know
frameworks.
E
Yeah,
I
I
think
it's
a
reasonable
question.
I
mean
I
think
some
of
the
answer
is
we
are
each
targeting
slightly
different
things.
E
I
mean
argo
workflows
has
a
different
set
of
like
scaling
targets
and
a
different
set
of
throughput
targets
and
a
different
set
of
isolation
targets
I
mean,
like,
I
said
the
reason
I
think
we
are
probably
one
of
the
slower
paced
things
as
far
as
like
how
much
throughput
we
go
through,
but
that's
because
we
really
need
to
make
sure
that
no
two
users
code
ever
touches
the
same
pod
together
or
you
know
no,
but
yeah
anyway.
Why
aren't
they
all
teched
on
is
also
a
question
worth
answering.
G
E
If
we
were
to
use
jobs,
we
would
only
allow
it.
We
would
only
configure
it
to
start
one
pod
because
we
wouldn't
want
to.
We
don't
want
to
run
the
work
twice.
G
E
G
I
was
just
wondering
if
we
and
if
we
use
the
like
the
the
other
approach
of
spawning
pods,
maybe
not
the
question.
G
Anyone
else
has
experience
work
like,
for
example,
if
you
spawn
multiple
pods
in
a
job,
can
you
share
volumes
in
them
like
or
you
have
to
mount
the
volume
separately?
How
does
that
work.
F
A
All
right,
thank
you,
everybody
and
see
you
next
week
I'll
be
uploading
this
to
youtube
for
people
who
didn't
see
it.
I
think
this
was
extremely
useful,
at
least
for
me,
it's
really
great.