►
Description
02:00 A glimpse of Argo at CERN
23:00 Argo Events Calendar Catchup
30:30 Argo Workflows v2.12 Preview
A
Cool,
thank
you,
bala.
Okay,
welcome
to
the
10th
2020
our
go
workflows
and
events
community
meeting.
We
started
this
at
the
beginning
of
2020
and
we
did
that
with
the
goal
of
kind
of
talking
a
lot
about
what
we're
doing
with
argo
workflows
originally
and
we've
expanded
that
to
include
events,
because
we
know
that
a
lot
of
people
are
using
events
when
they
use
argo
workflows.
A
If
you've
just
joined
the
meeting,
it'd
be
fantastic.
If
you
could
add
yourself
to
the
the
community
meeting
document
here,
it's
really
good
to
know
where
people
are
coming
from
and
what
kind
of
use
is
you
getting
our
workflows
and
events
for?
We
need
this
information,
so
we
can
make
sure
that
we
build
in
the
appropriate
software
features
and
we
kind
of
apportion
our
time
appropriately.
So
it
is,
it
is
it's
a
small
effort
from
you
but
incredibly
useful
to
us.
A
Let
me
give
you
just
a
little
bit
of
an
overview
of
today.
We've
got
a
couple
of
talks
here
from
kubecon
we're
going
to
be
giving
a
little
bit
of
discussion
around
the
catch-up
feature
which
bala
is
going
to
do
and
then
I'm
going
to
show
you
a
couple
of
the
new
user
interface
features
coming
in
to
2.12.
A
That's
our
plan
for
today.
If
you
want
to
ask
any
questions
during
the
course
of
today
feel
free
to
just
unmute
your
microphone,
if
you
think
it's
an
appropriate
time
to
ask
them
or
you
can
drop
them
into
the
slack
channel
and
you
can
ask
them
there
and
yes,
yes,
we
are
recording
this
people
always
ask.
Are
you
recording
this
and
yes,
yes,
we
are
okay,
clemens,
you
are
you
ready
to
take
over.
B
B
So,
first
of
all,
a
few
words
about
myself:
I'm
a
certain
research
physicist
working
on
the
cms
experiment,
the
large
hadron
collider
lhc,
at
cern
switzerland.
So
cern
is
the
european
particle
physics
laboratory
it's
in
the
border
region
between
switzerland
and
france
and
what
I'm
doing,
let's
say
every
you
know.
Everyday
life
is
analyzing
the
particle
collisions
provided
by
the
lhc
recorded
by
one
of
the
detectors.
The
particle
detectors
at
this
collider
ring,
which
is
the
cms
detector,
and
you
can
see
a
lego
model
here.
B
So
this
is
a
the
biggest
particle
accelerator
that
we
have
on
on
earth
is
the
biggest
human-made
one
has
a
circumference
of
27,
kilometers
or
17
miles
like
that,
and
it's
actually
the
the
coolest
place
on
earth,
because
it's
a
giant
fridge.
The
magnets
need
to
be
cooled
down
to
1.8
kelvin.
So
that's
about
minus
270
degrees
celsius,
or
I
think
I
looked
it
up.
460,
minus
460
degrees
fahrenheit,
so
this
is
really
cold
and
it's
actually
colder
than
the
universe.
B
And
we
need
that
in
order
to
bring
these
magnets
into
a
state
with
which
they
are
then
super
conducting
and
allow
us
to
bend
the
particle
beams
around
this
circle.
And
if
you
look
down
this
tunnel,
it's
a
fairly
straight
thing
and
only
bends
at
the
very
far
end.
So
we
really.
This
is
a
huge
detect.
Sorry,
a
huge
collider
and
it's
all
underground
about
one
kilometer.
B
Right,
so
what
is
high
energy
physics?
It's
about
trying
to
understand
the
smallest
building
blocks
of
matter,
and
I
already
mentioned
the
cms
detector:
that's
a
particle
detector,
which
takes
up
to
40
million
photos
of
the
collisions
provided
by
the
lhc
and
that's
per
second
and
that's
happening
effectively.
24
7
almost
all
year
long,
it's
not
happening
at
the
moment,
we're
in
a
shutdown
phase.
So
the
last
collisions
took
place
at
the
end
of
2018.,
we're
gonna
restart
collisions
next
year.
B
You
can
basically
you
know
we
that
billions
of
protons,
so
really
tiny
particles
collide
head-on
or
at
least
almost
head-on
in
the
center
of
these
detectors-
and
you
know,
one
one
picture
is
roughly
two
megabytes
and
if
you
want
to
store
that
this
is
kind
of
challenging,
so
we
can
actually
cannot
do
that.
We
can
say
get
a
brief
glimpse
of
that,
and
then
what
we
can
store
for
further
processing
on
disk
is
something
like
a
1000
of
those
photos,
and
we
call
these.
Then
events
that's
per
second.
B
So
in
total
we
were
actually
looking
here
at
terra
to
petabytes
of
data
and
we
analyze
them
using
c
plus,
plus
python
or
shell
scripts.
I
mean
we're
using
them
effectively
using
c
plus,
plus
and
python,
and
use
shell
scripts
for
steering.
So
this
is
really
a
big
data
analysis
and
also
the
detector
isn't
small.
I
mean
you
saw
the
lego
model,
but
the
actual
thing
is
weighs
14.
000
tons
has
a
height
of
50
meters,
the
length
of
21
meters,
and
it's
actually
a
compact
version.
B
So
even
the
atlas
detector,
which
is
the
one
shown
here
right
across,
it's
actually
bigger
than
cms.
It's
lighter
though,
but
we
have
around
100
million
electronic
channels,
so
you
can
effectively
translate
that
to
something
like
megapixels
if
you're
thinking
about
a
big
camera,
so
we
basically
take
photos
with
100
megapixel
crammer
40
million
times
per
second,
and
you
can
see
one
of
these
photos.
B
I
mean
it's
illustration
here
on
the
right
hand,
side
and
you
can
see
that
the
collision
basically
takes
place
in
the
center
of
the
detector
and
then
particle
sprays
go
in
all
kinds
of
directions,
and
basically
we
put
the
detector
there
to
record
everything.
That's
happening,
and
one
thing
that's
often
confused.
B
B
You
can
see
them
here
on
the
right
inside,
so
the
so-called
tier
zero
is
at
cern
it's
on
the
cern,
iit
computing
center
and
from
there
the
data
of
the
first
shot.
Reconstruction
of
what
we've
recorded
are
shipped
to
several
tier
one
sites
with
high-speed
links
they're
already
distributed
all
across
the
world.
B
We
also
have
one
actually
at
cern
so
slightly
bigger
tier
three,
though
the
sites
themselves
are
already
often
managed
using
kubernetes,
and
at
time
we
have
a
big
batch
computing
farm.
It
consists
of
around
230
000
cores,
it's
a
running,
hd
condor.
It's
a
high
throughput
computing
software
and
it's
running
around
150
000
drops
simultaneously
that's
a
peak
value
and
1.4
million
jobs
are
completed
per
day
and
the
let's
say
the
standard
workflows
for
the
cmx
experiment.
B
They're
executed
using
singularity
so
now
they're,
not
using
docker
but
they're,
using
singularity,
but
already
containerized,
workflows,
okay,
but
I
actually
don't
want
to
talk
too
much
about
say
this,
but
I
want
to
talk
about
a
different
aspect
of
a
high
energy
physics
workflow.
So
all
this,
what
I've
shown
you
here
in
the
in
the
previous
slide
is
already
largely
automated,
but
the
challenge-
and
that's
what
I
spent
most
of
my
time
on-
is
using
this
for
the
so-called
high-level
physics
analysis.
B
So
this
is
actually
then
addressing
a
particular
physics
question,
so
that
then
typically
results
in
a
paper
publication
and
there's
a
lot
of
metadata.
That
goes
into
the
physics
analysis
here,
so
the
data
sets
themselves
then,
of
course,
the
implementation
of
the
analysis
and
also
for
the
data
products.
There
are
lots
of
inputs
that
one
needs
to
handle
and
then
keep
track
of
and,
of
course,
use
version
control
systems
for
that.
B
We
call
it
scientific
linux,
sun
edition
6
will
reach
end
of
life.
I
think
the
end
of
next
month,
so
containerization
is
there
in
order
to
make
use
of
the
data
also
long
term.
Okay.
So
now,
when
it
comes
to
running
the
physics
analysis
itself,
what
would
we
have
to
do?
We
have
to
capture
the
software,
so
that
means
we
have
to
know
how
how
we
can
execute
the
individual
analysis
stages
and
also
capture
the
commands.
B
So
how
we
can
then
execute
this
include
all
the
dependencies
and
what
I'm
particularly
interested
in,
because
one
and
two,
let's
say
somewhat
solved
is
capturing
the
workflows.
How
do
you
connect
the
individual
analysis,
steps
and
then
there's,
of
course,
lots
of
research
ongoing
already,
so
several
tools
are
under
investigation
and
part
partly
used
by
smaller
groups.
So
there's
a
by
cern,
it
developed
a
product
and
that's
called
rihanna.
That's
a
an
implementation
of
the
common
workflow
language
has
a
clear,
high
energy
physics
focus
then
there's,
for
instance,
also
luigi.
B
That's
originally
been
developed
when
has
originally
been
developed
by
spotify,
there's
a
specific
add-on,
that's
called
law,
and
then
that's,
for
instance.
Also.
I
think
the
these
languages
or
these
workflow
languages
or
tools
won't
tell
you
much,
but
the
question
that
I
ask
myself
is:
can
we
actually
do
this
cloud
native?
You
know
in
particular
to
reduce
overall
maintenance
and
and
make
use
of
all
the
nice
features
that
kubernetes
has
and,
of
course,
the
the
solution
to
that
are
argo
workflows.
B
So
I
looked
into
that
a
bit
more
and
just
to
point
out
the
so
the
physics
analysis
I'm
talking
about
this
starts
where
the
automated
workflows
currently
end
and
when
you
develop
a
physics
analysis,
it's
done
in
an
iterative
way.
So
the
first
step,
which
is
a
highly
parallel
step,
is
actually
reducing.
B
The
data
sets
to
contain
only
events
of
interest
for
the
particular
analysis
using
using
let's
say,
first
pass,
so
I
would
usually
ship
my
code
to
one
of
the
grid
sites
all
over
the
world
and
say,
like
you
know,
I'm
interested
in
such
events,
then
these
events
will
be
say,
written
out
and
I'll,
then
analyze
them
in
subsequent
steps.
Steps
somewhat
interactively
so
I'll.
B
Okay,
and
just
to
give
you
an
idea
what
this
roughly
looks
like,
I
implemented
in
a
workflow
as
an
example
in
in
argo,
and
it's
really
nice
that
one
can
see
this
say
on
a
single
screen.
It's
somewhat
simplified,
but
I
think
that
the
the
main
point
here
is
that
it's
a
delightfully
parallel
thing.
So
let
me
give
you
some
idea
of
what
I'm
doing
here.
B
So,
okay,
I
create
some
output
directory
and
then
I
want
to
run
on
different
data
sets
both
the
actual
collision
data
recorded
and
the
simulation
that
I
think
is
relevant
for
this.
And
then
I
basically
ask
the
database
like
how
many
data
sets.
Sorry,
sorry,
how
many
files
are
actually
part
of
this
data
set
and
then
I
dynamically
scatter
the
workflow
to
lots
of
parallel
tasks.
So
this
is
what
you
see
here
and
afterwards
I
reduce
again
this
information.
B
So
I
merge
all
the
parallel
jobs
based
on
an
individual
data
set,
and
then
I
run
further
investigation
steps.
I
will,
for
instance,
make
a
couple
of
plots
so
in
figures
and
and
extract
a
couple
of
numbers,
and
I
optimize
further
so
that
my
analysis
is
really
top
notch
and
and
once
I'm
happy
with
that,
I
I
would
go
down
and
continue
with
further
further
statistic
in
another
and
then
usually
in
the
end.
B
I
end
up
with
a
single
plot
or,
let's
say
a
handful
of
pots
that
then
actually
make
it
to
the
final
paper
publication.
But
of
course
I
produce
actually
more
than
I
would
usually
say,
hundreds
or
thousands
of
plots
to
investigate
what
I'm,
what
I'm
doing
and
if
I'm
making
you
know.
If
I
find
I
should
go
back
one
step.
It's
really
important
that
I
can
move
from
one
step
to
the
other,
and
I
just
see
a
link
here
at
the
bottom.
B
My
signal
gets
scaled
away
almost
to
zero
and
that's
important
information
that
I
can
then
feedback,
for
instance
to
the
community
and
particularly
the
particle
physics
theory
community,
okay.
So
before
I
close,
I
just
wanted
to
point
out
what
are
typical
workflow
requirements
and
and
challenges
so
high
level
of
parallelization,
something
really
important.
I
recently
saw
that
there's
been
a
mapreduce
example
implemented,
so
I
think
that's
really
useful,
so
I
usually
scatter
and
gather
dynamic
dynamically.
B
B
So
I'd
have
to
look
into
more
details
and
implementing
custom
sensors
for
that,
so
that
I
avoid
re-running
the
same
step
again,
and
I
also
need
to
be
able
to
restart
and
stop
at
arbitrary
steps
in
in
in
the
workflow
and
that's
also
something
that's
possible.
So
that's
really
nice.
Another
thing
is
that
we've
got
the
grid,
but
even
though
we
have
several
hundreds
kubernetes
clusters
at
sun,
the
computing
power
for
typical
high
energy
physics.
B
B
I've
recently
implemented
a
custom
operator,
and
I
talked
about
that
at
kubecon
europe
earlier
this
year,
and
that
makes
it
possible
to
use
that-
and
I
think
something
that's
really
great
about
argo-
is
that
there's
this
feature
to
manage
arbitrary
q
and
it
is
resources
and,
if
you're
interested
in
how
I
did
that
you
can
have
a
look
at
this
talk
there.
Another
challenge
is
user
accounts,
so
cern
accounts
on
kubernetes
service
accounts,
so
we
need
to
have
some
kind
of
translation.
B
I
recently
saw
that
there
is
now
an
integration
of
decks
for
that,
but
I
yet
I
have
to
look
into
this
and
how
to
use
it
with
single
sign-on
and
all
auth
and-
and
one
particular
thing
is
that
certain
user
accounts
come
with
resources
that
need
to
be
accessible.
For
instance,
if
I
run
it
right
out
to
eos,
I'd
have
to
have
secrets
that
should
only
be
access
accessible
to
the
user.
Actually,
I'm
running.
B
So
there
are
a
couple
of
things
that
need
to
be
worked
out
on
the
technical
side
and,
of
course,
then
there's
a
socio,
sociological
part
of
it.
I
need
to
one
needs
to
train
physicists,
to
actually
use
these
new
tools
and
approaches,
and
I'm
I'm
planning
on
developing
further
tutorials
on
this
okay.
So
that's
already
the
end
of
my
talk.
I
just
wanted
to
point
out
that
I
recently
also
gave
a
webinar
on
using
argo,
cd
and
atsun
that
was
more
focused
at
the
sun
community.
B
This
is
not
the
argo
cd
meeting,
but
I
just
wanted
to
say
let
everyone
know
that
was
highly
appreciated
that
there's
this
nice
web
ui,
which
is,
for
instance,
not
there,
is
not
to
my
knowledge
in
influx
cd.
Okay.
Last
thing,
this
has
not
been
an
extensive
presentation
on
the
use
of
argo
workflows.
At
cern
I
mean
I
only
can
see
a
little
part
of
it.
There
are
thousands
of
people
working
there
and
I
know,
for
instance,
some
of
my
colleagues
also
using
this
as
part
of
kubeflow.
D
B
Yes,
yeah.
Definitely
I
think
this
would
be
a
great
thing
in
particular.
Let's
say
you
know
we're
producing,
also
new
simulation
samples,
our
new
data
coming
in
and
whenever
these
data
are
actually
available,
one
would
actually
want
to
trigger
a
workflow,
and
I
think
argo
events
would
be
really
useful
for
that.
B
A
Out,
thank
you
very
much
for
that
presentation.
Really
interesting.
I've
dropped
the
links
from
your
slides
in
to
the
zoom
chat,
so
people
want
to
go
and
dig
in
to
that
information.
You
can
do
that
now,
as
well
as
I'm
actually
gonna.
Take
a
good
look
at
the
argo
cd
presentation
as
well.
I'm
quite
interested
in
that
as
well.
For
you
know,
for
obvious
reasons,
do
you
have
any
any
more
questions?
Anybody
want
to
everybody's
loving
your
presentation
in
the
chat
by
the
way,
yeah
there's
a
great
positive
feedback.
A
Okay,
great
okay,
so,
unfortunately,
david's
had
a
problem
logging
into
zoom,
so
he
won't
be
presenting
this
week.
We'll
have
him
come
back
in
november
and
hopefully
we
can
address
whatever
whatever
zoom
issues
people
seem
to
be
having
today
by
then,
and
so
what
we're
going
to
do
is
we're
going
to
move
forward
and
bala
who's.
One
of
the
core
engineers
on
workflows
is
going
to
be
doing
a
short
presentation
on
a
catch-up
feature.
Bala.
Are
you
ready
to
go.
C
Yes,
I'm
I'm
ready
hi
hi
everybody,
I'm
bala
from
argo
team
intute,
I'm
going
to
present
to
the
they
can
catch
a
feature
in
argo
event.
So
the
input
batch
team
has
a
use
case
for
the
calendar
you
want.
So
then
they
need
to
stop
and
start
for
some
time,
but
they
like
to
catch
up
that
all
the
missing
schedules
between
that
start
and
stop
and
stop
start
period.
So
that's
why
we
start
analyzing
the
the
argo
catcher,
the
airflow
catcher
feature.
We
like
to
similarly
support
that
the
airflow
capture
feature
in
our
arduino
event.
C
C
We
started
with
the
use
cases.
What
are
the
things
we
need
to
support
it
so,
basically,
if
their
calendar
even
source
scheduled
for
10
minutes,
and
if
the
user
is
stopped,
that
calendar
event
and
start
after
some
time,
they
need
to
catch
up
that
all
the
schedules,
sometimes
if
it
is
any
any
any
problem,
the
cluster
like
the
node
failure
or
some
problem,
the
cluster
or
upgrade,
is
happening
so
that
time
all
the
even
source
pod
will
go
down
that.
I
might
know
that
all
the
the
duration
of
the
part
is
not
off
those
all.
C
The
schedules
will
be
missed
in
missed
for
when
it's
coming
back,
so
we
need
to
catch
up
that
so
for
that
one,
I
enhanced
the
the
calendar
spec
calendar,
even
spec,
to
provide
like
the
persistence
to
persist.
The
last
successful
event
in
the
conflict
map
and
the
user
can
define
that
a
catch-up
functionality.
C
So,
in
the
catch
of
functionality
you
can
the
user
can
enable
and
disable
the
capture
when,
when
it's
coming
back
the
part
and
the
the
user
can
define
what
is
the
maximum
duration
they
like
to
catch
up.
Suppose
if
the
event
is
down
for
like
a
one
day,
but
they
just
want
like
last
five
minutes
catch
up,
so
they
can
define
like
the
duration
in
the
match-
duration
here
so
for
here,
I'm
going
to
demo
that
I
have
the
same,
even
sources
created
in
my
local
and
which
was
running
fine
and
technically
I
deleted
it.
C
C
C
C
C
C
C
C
A
Great
stuff,
thank
you
very
much
bala.
So,
unfortunately,
dave
is
not
going
to
be
able
to
present.
Today
he's
had
issues
trying
to
access
zoom,
so
we're
going
to
reschedule
his
presentation
and
to
know
to
november.
In
the
meantime,
I
wanted
to
kind
of
just
talk
a
little
bit
about
version
212,
so
I'm
just
going
to
share
my
screen
with
you.
A
So
we
can.
We
can
talk
about
that
now.
Version
211
and
212
have
had
quite
a
number
of
changes
that
are
very
much
under
the
hood
changes.
One
of
our
goals
is
to
kind
of
really
reliably
run
very
large
workflows,
and
so
by
reliably
I
mean
that
we
want
to
be
able
to
run
workflows,
even
if
kubernetes
decides
to
do
things
like
delete
your
pod.
A
Underneath
your
you
know,
there's
some
kind
of
transient
network
error
and
by
by
very
large
workflows
we're
talking
workflows
with
nodes
in
the
ranges
of
10
to
20
to
30
000
nodes.
We
can't
actually
go
much
much
much
bigger
than
that,
because
I
should
actually
limit
in
kubernetes
to
how
many
pods
you
can
actually
run
at
the
same
time
so
that
most
of
those
most
of
those
changes
are
kind
of
under
the
hood
at
the
moment.
A
Okay,
so
obviously
you
guys
are
probably
familiar
with
the
user
interface.
Here.
I've
been
running
some
some
large
workflows,
I'm
going
to
point
out
some
new
details
in
the
user
interface
here
to
you
as
well.
So
the
first
detail
here
is
that
we
now
have
a
new
column
in
in
the
program
in
the
workflow
list,
and
actually,
if
you
go
into
a
particular
workflow
that
same
information
is,
is
shown
in
the
workflow
details.
Page
it'll
show
you
the
progress
of
the
workflow.
A
The
progress
is
calculated
as
the
number
of
nodes
in
your
workflow
that
are
completed
and
over
the
number
of
nodes
that
need
to
be
run.
This
can
actually
change
at
run
time
because
we
don't
know
when
we
start
your
work
for
the
number
of
nodes
that
it
might
contain.
So,
for
example,
you
might
have
a
single
step
that
runs
then
then
has
a
with
item
step
or
a
width
sequence.
That
runs
a
number
of
steps
and
it
might
initially
say
that
it's,
for
example,
zero
one
complete
and
then
suddenly
change.
A
A
The
second
feature
we're
adding
I'm
just
going
to
demonstrate
this
now
is
the
ability
to
kind
of
see
the
progress
of
the
workplace
that
one's
a
bit
too
quick.
So,
let's
see
if
I
can
start
another
one
up
to
see
the
progress
of
a
workflow,
you
do
need
one
that
takes
more
than
about
a
second
to
complete.
A
So,
okay,
you,
I
don't
know
if
you
caught
it
there,
but
this
work
only
runs
four
seconds
and
there's
a
little
progress
bar
that'll
appear
in
the
duration
column
that
it's
based
on
an
estimate
of
how
long
that
progress
takes
that
progress
estimate
is
a
bit
coarse.
It's
essentially
how
long
did
the
last
workflow
trigger
from
the
same
template,
same
chrome,
workflow,
template
or
the
same
workflow
template
take
if
your
workload
does
it
has
a
variable
fan
in
and
fan
out,
then
that
number
can
change
quite
a
bit.
A
A
A
If
it's
going
to
start
here,
we
go
so
you
get
a
progress
meter
in
in
the
main
node
here.
You'll
see
that
this
duration
meter
kind
of
ticks
up
here,
and
you
can
see
that
the
progress
currently
shows
me
of
of
you
know
different
numbers
depending
on
you
know
where
it's
got
to
in
the
progress
of
this
okay,
I'm
gonna,
I'm
gonna,
delete
this
one
because
so
it'll
be
enough
to
slow
my
computer
right
down.
If
I
leave
it
running.
A
Hopefully,
it
hasn't
caused
any
problems
already,
and
so,
while
it's
loading
there's
a
new
page
here
that
appears,
on
the
left
hand,
side,
and
this
is
called
workflow
reports.
This
is
kind
of
a
new
feature
I
can
go
into
here
and
I
can
choose
a
pre-existing
workflow
template,
and
this
will
then
load
up
a
graph
of
that
of
that
template,
and
it
will
provide
me
information
about
the
average
runtime
of
recent
executions.
It'll
show
me
a
graph
of
those
executions
as
well.
A
It'll
also
show
me
the
amount
of
cpu
memory
and,
if
you've
got
gpu
or
other
kind
of
resource,
it'll
it'll
show
those
in
the
graph.
The
the
use
case,
for
this
particular
pages
you
know
is,
is
my
workflow
taking
longer
is
my
pipeline
taking
longer?
Is
it
consuming
more
resources?
When
did
it
start
consuming
more
resources,
and
when
did
it
start
taking
longer
help
you
analyze
those
situations
where
you've
got
a
problem
and
kind
of
narrow
it
down?
Perhaps
a
particular
change,
or
you
know
again,
just
just
get
a
general
idea.
A
A
So
if
you're
using
sso
today,
you'll
know
that
our
back
automatically,
if
you
can
log
in
through
using
sso
the
service,
account
that
it'll
it'll
use,
will
be
the
argo
server
service
account.
That's
not
very
flexible
if
you
want
to
have
different
users
to
have
different
service
accounts
with
different
permissions,
so
the
most
common
configuration
for
sso
today
would
be
to
set
up
just
as
read-only,
so
people
can
see
everything
are
back
with.
A
We're
planning
to
move
to
v3,
not
necessarily
because
we'll
introduce
large
numbers
of
breaking
changes.
This
is
kind
of
forced
on
us
because
of
the
way
that
golang
does
go
modules
and
you
can't
actually
migrate
successfully
to
go
modules.
Unless
you
increase
your
major
version
because
go
mandates,
it's
not
great
most
other
languages,
don't
require
you
to
do
that.
A
Unfortunately,
it's
going
to
be
forced
on
us
and
as
part
of
that
work,
we
are
going
to
be
changing
the
user
interface
for
argo
workflows
to
make
it
a
separate
deployable
unit
that
will
allow
us
to
to
build
in
new
features
and
capabilities
into
the
user
interface.
Initially,
we're
planning
to
provide
some
new
views
related
to
argo
events,
to
allow
you
to
view
different
types
of
events
in
the
in
the
user
interface
and
also
your
configuration
and
understand
a
bit
about.
Why
did
my
workflow
trigger
what
was
that?
A
A
A
This
is
one
of
our
largest
releases
and
I
think
it
may
even
have
the
highest
number
of
pull
requests
and
the
highest
number
of
contributors.
We
typically
get
20
to
30
contributors
to
which
relates
this.
The
212
has
actually
had
40
41
different
contributors,
and
I
suspect
that
actually
might
be
higher,
since
this
blog
post
was
written
a
week
ago,
because
we're
still
adding
and
pull
requests.
I
I
know
that
one
of
the
questions
you're
going
to
ask
we
always
get
is
when
is
where
is
212
going
to
drop?
A
I'm
hoping
it'll
drop
within
the
next
two
weeks,
so
212.00
and
then
we'll
plan
to
probably
support
that
for
a
longer
period
of
time
than
other
releases,
because
people
tend
to
not
migrate
from
a
v2
to
a
v3.
Even
though
we're
going
to
try
very
hard
to
make
that
migration
almost
seamless
for
the
majority
of
users,
you
know
there's
always
kind
of
a
reticence
of
people
to
migrate,
so
we'll
be
back,
putting
bug,
fixes
and
and
so
forth,
from
v3
to
v2,
okay.
A
A
It's
always
fantastic
to
have
people
come
along
and
present
at
these
meetings,
so
kind
of
dm
me
on
the
slack
we'd
love
to
have
you
come
and
present,
or
even
work
with
us
on
blog
post
talking
about
the
stuff
that
you're
doing
we
do.
Would
you
really
love
that,
and
I
will
let
you
get
on
with
your
day,
have
a
wonderful
day.
Everyone.