►
From YouTube: CDF SIG Interoperability Meeting 2020-06-11
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
A
A
D
Work
for
Illumina
networks
at
the
moment
in
the
past
I
used
to
work
for
the
Linux
Foundation,
so
I've
managed
lots
of
different
CI
systems.
So
this
kind
of
thing
is
kind
of
interesting
for
me,
because
I
I
want
to
know
if
there's
easier
ways
to
manage
CI
systems
when
you're
using
you're,
not
particularly
using
any
specific
one
cool.
C
B
B
E
And
agenda
books
fully,
but
I
think
the
first
three
topics
will
be
hopefully
be
quick
and
then
we
can
have
some
conversation
around
this
reusable
libraries.
If
we
have
shown
and
others
here,
I
don't
Tracy
will
not
be
able
to
join
so
that
topic
we
may
need
to
move
next
meeting
and
then
we
have
only
as
Emily
I
mean
with
us.
Maybe
we
can
talk
about
the
work
stream.
We
went
through
and
see
ICD
and
then
max
joined
us
today
for
the
proposed
work
group
sake
CI
robots.
E
E
E
E
A
B
E
E
Yeah
I
think
I
put
the
link
on
top
of
that
Google
box.
The
meetings
folks
but
yeah
I
will
get
it
fixed,
I
mean
sorry
for
ya,
and
then
the
link
to
the
this
document,
plus
the
link
to
zoom
and
the
meeting
time,
will
be
included
in
me.
Agenda
mails
and
made
of
mating
males,
because
someone
on
the
slack
I
forgot
the
main
person
he
couldn't
locate
the
meeting
logistics
so
that
will
be
included
in
the
mail
in
the
male's
as
well.
E
H
E
And
a
nice
pinnacle
folks,
Tracy
is
not
here,
so
we
don't
know
the
states
with
it.
So
we
keep
them
open
and
the
actual
agenda
item
the
first
agenda
item
very
forward
with
the
sig
roadmap.
So
the
reason
why
this
point
is
in
the
agenda
is
that,
thanks
to
Tracy,
we
have
the
first
draft
available
on
Google
Docs,
and
it's
been
there
for
three
months
two
months,
maybe
at
least
two
months
I
am
wondering
if
it
makes
sense
for
us
to
kind
of
agree
on
that
version.
G
I
E
J
E
I
E
E
Okay,
then
relate
that.
Maybe
this
can
be
documented
in
the
way
posts
or
people
know
what
works
three
means
when
they
end
up
in
booklets
repository.
Maybe
we
can
create
a
simple
document
that
describe
this
type
of
approach,
saying
that,
okay,
if
people
won't
find
like-minded
people
and
focus
on
certain
areas,
they
can
reach
out
to
seek
present
their
case
and
ask
for
others
to
join,
and
then
we
kind
of
make
this
I,
don't
call
it
official
what
kind
of
official,
because
it
will
be
documented.
E
Okay-
and
that
was
it
for
that
topic-
and
the
next
topic
is
reusable
libraries
and
maybe
Christie
again.
I-
don't
want
to
put
you
under
this,
but
the
conversation
we
had
last
week
again
when
we
start
talking
about
focus
areas,
Tracy
brought
up
go
SEMS,
something
perhaps
could
be
housed
within
CDF,
and
there
were
some
corner
comments
about.
E
You
know
setting
some
boundaries
and
Gaussian
could
should
it
be
under
CDF
or
not
because
it
is
very
specific
to
go
itself
and
then
the
conversation
continues
with
having
a
focus
on
reusable
libraries
and
question
could
be
underneath.
So
maybe
you
can
talk
about
Who
I
am
everyone
knows
what
it
is
and
then
we
talk
more
sure.
H
Ok,
so
go
ACM
is
a
library
that
tries
to
abstract
at
cm
providers.
I,
don't
know
how
common
it
is
to
call
these
things
SCM,
but
that's
what
some
folks
are
calling
them
like
source
code
management.
So
this
is
things
like
github,
gitlab
bitbucket.
The
idea
of
go
SCM
is
that
it's
a
go
library
lets
you
interact
with
all
of
those,
as
if
they're
the
same
so
you
can.
H
You
could
write
the
same
like
you
basically
have
like
one
abstracted
common
interface
that
lets
you
create
a
pull
requests,
maybe
generically
and
that's
something
you
could
do
with
any
of
those.
It
gets
a
little
bit
rocky
in
that
some
of
the
concepts
don't
translate
between
all
of
the
SCM
providers
like
there
are
subtle
differences
between
them
like
I,
think
that
not
all
of
them
support
labels,
for
example.
H
That
might
be
a
bad
example,
but
there
definitely
are
some
things
that
you
can
do
to
some
of
them
and
can't
do
to
all
of
them,
but
go
SCM
as
a
library
that
tries
to
make
it
easy
to
interact
with
them
and
Tecton
has
used
go
SEM
a
bit
in.
We
have
some
abstractions
over
interacting
with
a
pull
request
and
we
used
that
library
a
bit
of
the
history
with
it
is
that
the
go
SCM
library
was
created
by
the
folks
at
drone.
H
But
then
the
folks
working
on
Jenkins
X
ended
up
forking
it
because
they
wanted
to
make
some
changes
to
the
way
the
library
works,
and
so
now
they
maintain
a
fork
in
the
Jenkins
xorg
of
go
SCM.
So
now
there
are
two
versions
at
least
of
this
library.
Tecton
is
using
the
version
that
was
forked
by
the
Jenkins
X
folks
and
then
a
while
ago,
I'm
trying
to
think
of
what
the
reason
was
for
this.
H
Oh
yeah,
I
guess
a
while
ago,
I
started
a
discussion
with
some
of
the
I
think
at
the
beginning
of
this
year,
with
some
of
the
Jenkins
X
folks
about
like
did
we
want
to
try
to
upstream
those
changes.
Did
we
want
to
try
to,
like
even
I,
think
at
the
time
I
was
suggesting
that
maybe
go
SCM,
be
like
a
Tecton
project
or
something?
H
H
B
H
That's
a
really
good
point:
I'm
just
I'm,
not
super
familiar
with
the
library
myself,
so
I'm,
just
like
glancing
through
the
notes
right
now,
but
definitely
definitely
there
is
because
there
is
a
common
interface
within
the
code.
That's
used
for
all
of
them
and
I
think
it
contains
things
like
pull
request,
labels,
checks
and
statuses,
I
believe
so
yeah.
That
makes
a
lot
of
sense.
That
could
be
interesting
even
to
just
extract
that
terminology
from
a
project.
E
Think
this,
like
reusable
libraries,
I,
think
that
was
kind
of
in
one
of
the
CDF
documents
and
also
in
sig
document.
So
again,
if
you
don't
talk
about
go
SEM
specifically,
this
area
seems
to
make
sense
for
the
sig
to
investigate
what
libraries
are
out
there
and
look
for
possibilities
on
at
least
highlighting
them.
Perhaps
not
fixing
everything,
but
just
finding
them
out
and
sharing
with
the
rest
of
the
ecosystem.
J
Additionally,
it
may
be
interesting
for
us
to
have
Andrew
bear,
do
a
presentation
on
Lifehouse,
which
is
a
it
will
probably
be
spun
out
as
it's
an
individual
project,
but
it
is
basically
Jenkins
X's
rewrite
of
prowl,
and
it
is
so
that
Jing
is
actually
easily
used
with
more
SEM
providers
and
it
must
be
using
the
go
SEM
for
sure.
But
I
should
have
Andrew
come
and
speak
to
us
more
about
that,
because
it
does
enable
a
lot
more,
and
it
could
be
very
interesting
for
this.
Discussions
was
everything.
E
E
I
I
So
we
actually
renamed
it
as
the
first
thing
to
events
in
CIC
D,
which
means
that
it
can
be
used
not
only
for
driving
things
in
clcd,
but
also
for
notifying
other
tools
or
external
systems
or
whatever
using
that.
So,
apparently,
we
will
not
restrict
ourselves
to
any
specific
area
when
it
comes
to
events,
but
but
anything
related
to
that
speed.
We
might,
of
course,
restrict
ourselves
play
around
if
we
say
that
we
can't
can't
really
handle
it
all
in
this
work
stream,
but
we
start
off
with
a
more
generic
heading.
I
How
the
workstream,
yeah
I,
think
we're
current
kind
of
a
fruitful
first
me
think
we
discussed
a
bit
terminology
example
what
an
event
is
and
what
an
event
is
not,
and
such
things
and
the
outcome
from
this
first
meeting
is
actually
stored.
Right
now
in
github
in
the
there
is
a
new
folder
for
the
work
streams
in
the
interoperability,
github
project
and
I've
added
the
the
minutes
of
meeting
from
our
first
meeting
in
there.
I
A
A
E
E
E
I
Comment
from
either
I'm
not
sure,
really
how
valuable
this
is
to
publish
birthday
unknown
on
that
YouTube
channel
I'm,
just
afraid
that
we
pollute
the
channel
with
with
a
lot
of
detail.
Discussions
with
might
not
not
be
interesting
to
look
at.
Of
course,
if
there
were
like
presentations
or
or
I,
don't
know,
maybe
grounds
for
some
decisions
or
something
that
we
would
need
to
record.
I
Of
course,
that
could
be
something
that
would
be
valuable
to
have
there,
but
I'm
not
sure
that
all
our
discussions
already
valuable
to
have,
but
at
the
same
time
I
don't
either
competing
proposal
where
to
put
it
so
I,
guess
it's
better
than
nowhere.
I
know
Andrea.
She
also
commented
if
you
have
any
other
ideas.
B
H
Don't
know
if
it
would
work
for
this
group
or,
if
it's
any
better,
but
in
the
for
the
Tecton
working
groups
we
it's
kind
of
annoying
because
you
have
to
upload
the
file
and
it's
not
quite
the
nice
interface
that
YouTube
is,
but
we
we
upload
all
the
recordings
to
a
share
share,
drive
that
everybody
in
the
community
has
access
to.
So
it's
not
on
YouTube,
but
you
can
access
the
recordings.
I
do
think
it's
valuable
to
make.
Referring
is
available
for
folks.
I
H
Think
I
mean
I,
think
anyone
can
make
one
I,
don't
know
exactly
how
it
works
like
for
Tecton.
We
have
like
a
community
drive
and
then
we
just
share
it
with
like
a
Google
group.
I,
don't
know
if
you
can
make
it
access
accessible
to
everyone.
So
that
is
one
barrier
that
you
have
to
be
part
of
the
Google
group,
but
I
think
anybody
can
make
it
chair,
drive
I,
don't.
G
It
would
be
I
think
fee
accounts
have
a
little
bit
date,
I,
don't
know
exactly
what
it
is
and
with
video
files
it
would
pretty
soon
fill
up,
but
I
mean
if
it's
any
worth.
Maybe
just
sticking
with
YouTube
might
be
a
good
idea
from
an
accessibility
perspective
so
that
it
just
gets
more
accessible
for
new
folks
to
get
a
handle
of
of
these
meetings
and
their
recordings,
which
otherwise
would
be
slightly
hard
to
find
through
the
dogs.
Just
my
two
cents.
Yes,.
H
E
Maybe
we
can
ask
done
and
Jackie
for
guidance.
Maybe
they
already
thought
about
these
things,
and
then
we
can
take
this
topic
more
generally,
like
what
to
do
with
like
non
meeting
type
of
recordings
and
see
what
happens
until
that
happens,
then
the
recording
could
stay
where
it
is
now,
unfortunately,
I
mean
yeah.
E
The
meeting
recordings
are
on
YouTube
in
CDF
channel
in
sig
interval
to
play
at
least
like
you
get
all
of
them
there,
but
yeah.
Let's,
let's
part
this
discussion
because
we
are
coming
closer
to
the
you
know,
presentation
and
then
workstream
need
to
figure
this
out
like
there
are
two
you
know
ideas
like.
I
Yeah
sorry
for
putting
us
in
this
direction
to
discuss
that
too
long,
but
about
the
works
team
that
we
have
I
mean
yeah.
We
had
quite
a
few
discussions
there
and
if
I
think
it
was
a
very
good
startup
meeting,
I
don't
know
if
anyone
else
of
you
and
Ray
also
remain
want
to
fill
in
anything
from
that
meeting
or
I.
I
E
I
E
F
F
I'm,
actually
working
with
tons
of
different
companies
together
implementing
actually
cloud
native
platforms
like
Cuba,
neatest
and
and
support
them
also
was
deploying
applications
and
of
it
and
have
recently
not
raised
observed
in
the
past
years,
is
basically
that
all
of
those
companies
try
to
leverage
their
CI
CD
pipelines.
So,
besides
the
fact
that
they
are
switching
around
tools
all
the
time
they
try
to
implement
scripts
or
sometime
robots,
which
support
in
the
work
of
on
this,
the
CI
CD.
F
So
what
could
this
be?
Their
stuff,
like
just
random
labeling,
so
basically,
for
example,
stop
the
active
testing
of
an
often
CI
CD,
for
example,
just
because
that
previous
test
before
failed
and
should
not
go
on
with
it
or
something
isn't.
Certificate
didn't
signed,
and
some
stuff
like
this.
But
this
can
be
also
like
was,
for
example,
the
robot
framework,
which
is
actually
testing
framework.
So
it's
something
which
basically
is
how
to
say
it.
The
CI
CD
testing
framework,
which
runs
in
parallel
and
gives
feedback.
F
So
it's
always
a
spin-off
needs
to
hold
or
stop
the
current
pipeline.
Do
is
testing,
and
this
can
be
massively.
We
have
seen
some
of
the
clients
where
this
testing
takes
takes
half
a
day
or
a
day
until
there's
coming
some
feedback,
but
of
course,
there's
also
some
more
human
interaction
frameworks
like
the
bot
cube,
which
is
basically
yeah.
You
could
sing
summarize
it
under
chet,
ops,
for
example.
F
So
after
the
first
discussion,
I
try
to
rephrase
and
add
some
little
bit
more
context
to
it,
because
I
think
it's
could
be
quite
feasible
to
to
dig
deep
into
it
and
find
their
common.
First
of
it
and
find
tools
for
four
different
problems,
basically
and
how
they
can
integrate
and
if
there's
a
possibility
to,
maybe
in
in
some
way
to
to
harmonize
it
so
basically
to
find
a
way
how
all
of
these
tools
can
be
exchanged
can
be
really
easily
integrated,
of
course,
is
also
something
would
sort
of
quite
frequently
see.
F
F
F
Potentially,
it
could
fit
also
to
the
events
in
the
CIA
CD,
because
I
mean
okay.
Events
are
on
a
once
in
a
way
of
how
you
can
get
some
information
and
a
standard
way
out,
but
even
driven
means
that
you
can
have
bi-directional
communication
with
a
standard
format
and
I.
Think
in
the
end,
if
you
want
to
integrate
such
tools,
you
have
jet
ops
or
labeling
or
different
testing
frameworks.
Do
this
event-driven
would
actually
allow
to
be
more
exchangeable
on
this
place.
B
So
I
completely
get
your
idea,
but
maybe
this
would
require
a
little
bit
longer
discussion
and
maybe
really
invent
invent
is
driven
back
string,
which
we
already
have
would
be
a
great
place
to
start
this
discussion.
So
if
you
would
like
to
join
us,
I
see
so
that
your
topics
to
this
into
this
topic
area.
F
Yeah
for
sure,
when,
when
you
give
a
shot
summary
of
what
you
have
discussed,
which
new
way
of
not
was
not
aware
of
that,
there's
an
events
and
the
ICD
working
group
already,
but
I
think
it
would
actually
fit
quite
well
because
I
think,
as
I
said,
it
would
be.
The
the
right
interface
in
the
end,
I
believe
to
think
and
design
everything.
What's
going
into
this
direction.
B
E
To
highlight
something,
thank
you
on
there
for
comment,
but
the
the
proposal
max
have
is
actually
to
the
talk
so
and
I
don't
think
in
CDF
we
have
like
we
have
any.
You
know,
power
to
you,
know,
work
under
this
seek
or
in
this
work
stream.
So
it's
like
Max
is
just
no
here.
He
is
being
nice
and
talking
about
this.
So
again,
if
you
have
comments,
maybe
you
can
put
under
the
pull
request,
so
talk.
E
People
can
also
see
in
the
conversation,
and
they
can
perhaps
they
take
this
as
an
input
to
no
further
discussion
on
the
talk
when
it
comes
to.
If
this
seek
or
work
group
should
be
created
or
not,
and
it's
good
that
if
max,
can
join
two
events
in
CIC,
diverse
stream
as
well,
but
you
know
we
can't
decide
it
should
be
under
this
seek
or
on
the
debt
work
stream.
E
Just
under
as
if
you
can,
if
you
don't
mind
if
you
can
put
a
comment
on
with
the
PR
suggesting
this,
so
then
Lawrence
can
also
see,
and
others
can
see
a
conversation
and
the
max
take
takes
it
from
there
and
discusses
with
talk
further.
Maybe
it
comes
under
this
shake
or
that
work
stream
or
goes
with
me
work
stream
or
seek
sure.
C
C
E
C
Yeah,
let's
see
if
we
can
get
this
working,
so
can
everyone
see
my
screen?
Yes
also
present,
everyone
can
still
see
my
screen,
yep
perfect,
so
hi
everyone,
my
name
is
Danny
Thompson
I'm,
a
software
engineer
and
Intuit
and
I
work
on
our
girl,
rollouts,
a
progressive
delivery
tool
on
kubernetes
and
I'm
gonna
kind
of
give
a
brief
overview
of
it
today
with
a
quick
demo,
but
before
I
dive
in
I
kind
of
want
to
help
set
the
stage
a
little
bit
and
kind
of
explain
some
background
about
into
it.
C
So
Intuit
has
made
a
significant
investment
into
kubernetes
internally,
so
we
have
a
internal
platform
that
we
have,
that
we
offer
to
our
developers
so
that
they
can
deploy
their
applications
onto
various
kubernetes
clusters.
Well,
our
central
platform
team
kind
of
manages
and
our
creates
those
clusters
for
them,
and
so
along
the
way
we
now
have
over
1200
developers
using
this
platform
and
sits
into
it's
kind
of
a
30
year
old
company.
C
We
kind
of
have
a
wide
variety
of
kind
of
different
services,
so
we
have
some
larger,
more
monolithic
applications
and,
on
the
other
end
of
the
spectrum,
we
have
some
really
focused
micro
services
and
so,
as
a
result
with
this
many
different
developers
kind
of
developing.
On
top
of
our
platform,
we've
kind
of
gotten
a
lot
of
different
use
cases
that
we
need
to
solve
for
their
deployment
needs
and
so
most
of
Intuit.
C
C
So
if
users
want
to
do
anything
like
blue,
green
or
canary,
if
they're
kind
of
hosed,
because
they
or
they
have
to
orchestrate
it
themselves
and
even
then
the
rolling
update
strategy
kind
of
doesn't
provide
a
lot
of
flexibility
in
terms
of
how
how
you
kind
of
do
that
rollout
like
it
allows
it,
doesn't
give
you
a
lot
of
options
to
say
how
fast
you
want
to
roll
out.
Nor
does
it
kind
of
say,
give
you
any
functionality
to
say:
stop
this
rollout.
C
If
X,
Y
or
Z
is
happening,
and
like
the
theory,
you
could
do
some
of
this
with
readiness
probes,
but
also
at
the
same
time
that's
not
a
good
fit
of
kind
of
for
readiness
probes,
not
really
what
readiness
fronts
are
built
for
and
so
kind
of.
With.
All
of
this,
we
realized
that
we
weren't
happy
with
the
native
deployment
object
and
so
from
there
we
said
okay.
Well,
if
we
wanted
to
change
this,
what
would
it
look
like?
C
Well
here
is
kind
of
the
long
list
of
use
cases
that
we're
trying
to
solve
for,
but
a
couple
ones
I
want
to
highlight-
are
adding
these
more
advanced
strategies
like
blue
green
canary
having
the
ability
to
kind
of
an
abort,
a
rollout
based
off
of
some
failed
metric
and
being
able
to
kind
of
fine-tune
those
metrics.
That
really
has
a
good
representation
of
this.
Is
your
application
in
a
healthier
and
healthy
state
and
really
giving
these
metrics
or
leaves
allowing
our
users
to
define
their
own
metrics
that
they
find
useful
for
their
application?
C
And
so
with
that
we
came
up
with
our
robots,
so
kind
of
the
first
phase
of
our
go
rollouts
is
we
kind
of
call
it
like
deployment
plus
plus
it
serves
as
a
drop-in
replacement
for
the
deployment
object
and
instead
of
using
the
rolling
update
strategy,
we
add
two
new
strategies,
one
being
blue,
green
and
the
other
being
canary
and
as
big
practitioners
of
get-ups.
We
really
wanted
to
make
sure
that
this
rollout
object.
It
was
declarative
and
get-ups
friendly,
which
also
made
it
a
lot
easier
to
integrate
it
into
our
other
argo
project
Argosy.
C
So,
okay,
this
is
still
pretty
high
level
at
this
point,
I.
Why
don't
I
show
you
what
a
deployment
looks
like
so
or
sorry
our
rollout
looks
like,
and
so
here
here's
a
rollout
object.
The
rollout
controller
is
responsible
for
basically
taking
an
existing
roll
out
and
creating
scaling
and
deleting
replica
sets
based
off
of
that
rollout
object
so
similar
to
a
deployment
object.
We
have
a
spec,
so
this
pack
is
mostly
identical
to
the
deployment,
so
you
can
see.
C
There's
the
pod
template
spec,
the
you
can
specify
number
of
replicas
and
we
also
kind
of
left
some
other
fields
out
for
brevity,
but
that
that
very
much
is
a
easy
transition
from
for
any
users
who
were
using
a
deployment
to
they
roll
out.
This
side
of
the
speck
is
gonna,
be
the
same.
Now
what
users
can
do
with
a
roll
out
that
they
can't
do
with
the
deployment?
Is
they
can
specify
a
strategy?
C
C
Then
we
set
the
weight
and
when
it
sorry
when
I
say,
set
the
weight,
I
mean
direct
60%
of
traffic
to
the
new
version
or
the
canary
and
have
40
go
to
the
old,
but
will
basically
execute
each
of
these
steps
to
kind
of
transition
from
the
stable
version
to
the
new
version.
That's
specified
in
your
rollout
spec
so
with
that
this
actually
got
us
decently
far
we're
able
to
on
board
a
number
of
applications
just
with
the
blue,
green
and
canary
strategy
alone,
but
we
kind
of
realized.
C
C
C
C
So
up
top
it's
a
bunch
of
metadata,
you
can
see
it's
clearing
strategy,
it's
executed,
all
the
stats,
here's
the
image
it's
running
and
then
below
here
we
have
the
kind
of
a
visual
representation
of
the
rollout.
So
you
can
see
here
we
created
a
rollout,
it's
healthy
that
will
upgraded
replica
set
which
is
healthy,
and
then
it
also
created
an
analysis
run
which
I
will
get
back
to
you
in
a
minute,
but
why
don't
I
show
you
our
UI
so
that
rollout
we're
running?
C
Basically,
this
is
the
front
the
UI
of
the
of
that
rollout.
So,
basically,
whenever
with
this
page,
whenever
one
of
these
floating
dots
goes
across
the
screen,
that
represents
a
request
of
the
back
end
and
back
back
and
basically
returns
a
color.
So
in
this
case
it's
returning,
all
blue,
and
so,
if
I
refresh
the
screen,
you
can
see.
I
also
have
this
bar
on
the
bottom.
That
bar
is
a
representation
of
the
percentage
of
requests
for
that
color.
So
right
now
we
have
a
hundred
percent
blue.
C
So
what
I'm
going
to
do
now
is
I'm
going
to
go
to
the
command
line
and
I'm
going
to
a
command.
So
you
set
the
image
from
blue
to
green,
and
so
this
is
just
kind
of
a
convenience
function
around
kind
of
updating
the
image.
So
you
can
see.
We
now
brought
up
a
new
canary
image,
green
and,
as
a
result,
we
see
that
the
rollout
starts
progressing
to
the
new
version.
C
So
the
first
step
that
we
saw
in
the
slides
was
that
first,
it
sets
its
weight
to
40%,
and
so
you
can
see
here
now
in
order
to
reach
40%,
we
scaled
up
two
new
pods
for
the
new
replica
set
and
then
scaled
down
to
from
the
old
to
reach
to
a
ratio
of
40%,
and
you
can
see
in
the
cui
now
we
have
kind
of
a
slit,
so
right
now
about
40%
is
being
split
between
the
40%
is
being
sent
to
the
green.
Well,
60
is
still
going
to
the
blue.
C
C
We
had
a
fail
with
our
analysis
run,
and
so
this
really,
then
the
raw
realized
hey.
This
is
a
failed
deployment,
so
I'm
going
to
scale
the
two
pots
that
we
brought
up,
and
so
then
it
also
scaled
up
the
old
replica
set,
and
so
you
can
see
now
we're
back
at
a
hundred
percent
blue
traffic
and
so
I'm
gonna
reset
that
air
rate
back
down
to
zero.
Just
so
that
I
can
retry
the
deployment
first
re,
the
rollout
and
then
kind
of
we
can
have
it
progress
all
the
way.
C
C
And
so
you
can
see
now
it's
starting
to
try
to
get
to
a
weight
of
60%.
It's
gonna
wait
about
10
seconds
and
once
it
waits
10
seconds
we'll
go
up
to
80.
We
didn't
wait,
another
10
and
then
fully
rollouts
the
new
version,
all
the
while
this
analysis
run
is
still
running
in
the
background.
Yet
as
soon
as
we
finish,
this
deployment
or
at
least
finished
progressing
to
this
new
version.
This
analysis
run
will
finish
because
we
only
run
this
analysis
during
the
kind
of
transition
to
a
new
version.
C
C
So
that's
just
a
brief
overview
or
a
brief
demo
of
the
Parker
rollouts,
just
to
kind
of
help
quickly
explain
some
of
that
magic
and
I'm
gonna
try
to
fly
through
it
a
bit
just
so
we
can
have
time
for
questions.
So
this
is
an
analysis
template
the
analysis.
Template
basically
allows
you
to
define
one
or
more
metrics
that
you
want
to
monitor.
One
of
the
things
we
really
try
to
do
with
the
analysis.
Template
was
try
to
make
a
support,
multiple
providers
so
right
now
we
support
things
like
for
me.
C
With
that,
so
you
can
see
within
this
Prometheus
provider
you're
providing
a
prompt,
UL
query
and
an
address.
So
that's
the
the
analysis
run
is
going
to
basically
query
Prometheus
for
this
information.
Then
it's
going
to
compare
it
to
this
success
condition
and
you
can
kind
of
define
different
success
conditions
using
a
we.
We
use
this
library
that
we
found
that
allows
you
to
kind
of
write,
more
complex
expressions
to
basically
evaluate
the
results.
C
So,
for
example,
if
you
were
provider
returns
an
array
you
can
use
kind
of
these
built
in
functions
like
any
all
filter
with
that
also
have
an
interval,
and
the
last
thing
I'll
kind
of
touch
to
before
we
move
to
Q&A.
Is
we
want
these
analysis
templates
to
be
parameterized?
All
this
allows
us
to
basically
kind
of
create
templates
that
can
be
shared
across
organizations
and
communities,
and
we
kind
of
see
the
templates
as
a
way
to
kind
of
create
a
make
it
easier
for
users
just
to
kind
of
pick
and
choose
the
templates.
C
C
The
deployment
object
doesn't
provide
any
strategies
for
canary
or
blue
green
or
even
a
base
a
be
testing.
The
deployment
object
only
offers
the
rolling
update
strategy
and
the
recreate
strategy,
be
that
being
said,
I
think
the
canary
strategy
that
I
just
showcased.
It
is
very
similar
to
the
rolling
update.
The
difference
I
would
say
is
that
the
canary
strategy
that
I
showed
you
gives
you
more
fine-grained
control
about
how
you
want
to
go
from
version
1
to
2.
You
can
say:
ok,
I
want
to
create
one
pod.
C
B
I
would
also
have
a
few
questions,
so
my
first
question:
is
you
mentioned
that
a
granades
get-ups
friendly?
Does
this
also
mean
that
you
can
persist
the
state
of
the
canary
canary
in
the
pitch
repository
so,
for
example,
currently
it's
40%
or
not,
or
as
far
as
I
know,
you
only
have
this
in
the
state
of
the
Agora
not
recess,
but
it's
not
written
into
the
git
repository
right,
yeah.
C
B
And
second,
you
can
pause
their
rollout
for
some
duration
to
your
auto
plan
and
to
not
use
iteration
instead,
for
example,
use
number
of
users
which
have
accessed
a
website
which
is
much
better
because
that's
imagine
you
are
doing
the
canary
during
the
night.
Of
course,
you
don't
have
that
much
users
and
you
probably
won't
run
into
to
an
error,
and
so
the
canary
completes
successfully
and
therefore
the
duration
is
sometimes
it's
not
really
the
best
metric.
You
would
say.
C
No
definitely
agree.
Duration
is
a
bit
of
a
kind
of
a
blunt
tool.
I
think
what
you
could
do
there
is.
You
could
probably
create
an
analysis
template
that
basically
queries
that
Prometheus
back-end
to
say:
okay,
how
many
users
have
you
had,
and
so
basically,
if
it's
below
a
threshold,
don't
don't
return
successful
but
also
don't
return
a
failure,
and
then
you
could
have
another
metric
that,
within
the
analysis,
template
that
says.
B
C
One
thing
that
deployments
do
that
we
kind
of
took
from
the
deployments
is
that
when
they
deployments
create
a
replica
site,
they
inject
a
label
called
pod
template
hash
that
pod
template
hash
is
generated
from
the
hash
of
the
spec
template
within
the
deployment.
And
so
when
you
look
at
a
replica
set,
for
example,
you
see
it's
like
usually
deployment
name
hash.
That
hash
is
the
hash
of
the
spec
template.
C
From
there
we
can
also
specify,
in
the
rollout
like
add
this
hash
as
an
argument
to
the
analysis
template
so
like
in
the
analysis
template
you
would
have
an
argument
saying
pod
template
hash,
then,
within
the
rollout
we
have
a
feature
of
saying.
Okay,
when
you
create
this
analysis
run
inject
this
argument
and
we
want
you
to
inject
the
new
pod
template
hash,
and
so
that's
how
we
would
identify
the
new
version.
That's
mine.
K
Okay,
so
thank
you
for
the
presentation.
I
also
agree:
what
drove
you
to
develop?
Arbor
rollouts,
because
I
know
flagger,
for
instance,
was
already
in
place
at
the
time
of
developing
animal
robots
and
I
was
just
wondering
if
it's
just
the
better
integration
with
Argos
city.
When
it
comes
that
drove
you
to
develop
it
in
the
first
place
or
what
was
it
that
you
wanted
to
do
with
it?
Yeah.
C
C
There's
kind
of
actually
there's
two
things,
one
at
the
time
when
our
garage
started
like
I
think
it
only
started,
maybe
a
couple
months
after
flagger
so
part
of
it
one.
We
didn't
really
see
flagger
at
the
time
and
then
we
started
off
more
trying
to
solve
with
Bluegreen
use
case,
since
that
was
kind
of
the
initial
problem
statement
that
we
are
trying
to
kind
of
solve
to
solve
within
just
all
some
of
our
problems
within
into
it,
but
I,
think
kind
of
between
flagger
and
our
girl
rollouts.
C
They
both
kind
of
take
very
they,
are
solving
very
similar
problems,
but
kind
of
take
different
approaches
where
flagger
kind
of
takes
more
of
an
approach
of
copying
their
deployment
over
and
running
two
copies,
while
our
go
Roth's
kind
of
just
takes
over
the
deployment
project,
object
and
so
I
think
both
of
them
have
pros
and
cons
to
their
approaches.
But
for
us
we
found
that
it
was
kind
of
easier
for
our
developers
to
kind
of
conceptually
understand,
because
they're
still
modifying
the
same,
almost
the
same
object,
except
instead
of
it
being
a
deployment.
C
E
So
the
give
action
point
to
everyone
who
joins
to
our
meeting.
All
right.
Can
you
upload
the
slice
we
have
shown
to
sick,
sorry,
CDF,
presentations
repository?
Let
me
try
to
put
that
link
to
chat,
so
people
can
fetch
the
slides
to
look
at
for
offline,
and
perhaps
you
can
include
the
links
to
our
NGO
projects.
You
know,
may
list
or
module
options
we
have
there,
so
people
can
join
two
toes
as
well
so
and
I
think
we
are
5
min
so
time.