►
From YouTube: SIG Interoperability Meeting - Feb 17, 2022
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
B
A
Good
feeling
pretty
good
about
a
lot,
I'm
really
excited
for
this
meeting.
I'm
really
glad
that
anders
is
going
to
join
us.
Actually,
I
feel
like
that'll
yeah.
A
Oh,
hey,
I'm
the
outlier,
london.
D
Hello,
can
you
hear
me?
Yes,
okay,
great
yeah,
I
just
got
these
new
headphones.
So
it's
still
a
new
experience.
D
Yeah
good
to
be
here,
let's
see
here.
A
A
B
D
Okay,
yeah
yeah:
this
is
it's
it's
starting
to
get
lighter,
which
is
really
what
I
care
most
about.
C
E
E
I
am
durango
colorado,
so
southwest
corner
yeah.
Did
you
escape
a
little?
I
mean
I
did
when
I
was
young
here
in
denver,
it's
kind
of
difficult
to
get
to
skiing,
there's
like
one
road
and
everyone's
on
it.
So
if
you
really
want
to
go
skiing,
you
need
to
go
during
the
week
and
get
up
really
early
to
go.
E
Nice,
I'm
gonna
be
in
stockholm
for
the
first
time
in
february
or
in
sorry
may,
oh
or
for
a
j
focus.
It
was
gonna,
be
in
february.
D
Why
were
you
coming?
Was
it
j
focus
or
yes,
j
focus,
okay,
cool
yeah.
D
Yeah,
no,
it
wasn't
job
on
us,
but
it
was
just
other
other
jobs
and
other
requirements.
So
and
I'm
I'm
more
on,
you
know,
like
advocacy,.
D
A
Alright,
we
must
get
started
since
anders
is
joining
us
for
the
second
time
today,
but
we
do
have
a
number
you
know.
Maybe
we
should
go
around
and
and
introduce
ourselves.
E
Melissa
all
right,
I'm
melissa,
mckay.
I
am
with
jfrog
right
now.
I've
been
with
jfrog
now
for
two
years
as
a
developer
advocate
and
prior
to
that
I
was
a
developer
and
software
engineer
at
various
companies.
Primarily
java
server
side
was
my
expertise,
but
I
rarely
meet
a
java
developer
these
days
that
aren't
doing
other
things
now
go
python.
E
Obviously,
a
lot
of
shell
scripting,
the
more
we
get
involved
in
devops
the
more
we
need
to
learn
other
things.
So
those
are
my
interests
right
now
and
definitely
enjoying
the
advocacy
role.
D
Nice
yeah,
I'm
anders
I'm
a
developer
advocate
at
styra,
which
is
the
company
behind
the
open
policy
agent
project,
which
is
yeah.
A
graduated
cloud
native
computing
foundation,
project
focus
on
policy
policy,
offering
policy
enforcement
across
the
whole
like
connect,
stack,
yeah,
and
I
have
a
background
in
development
and
primarily
focused
on
kind
of
identity,
security.
B
Well,
next
facility
from
ericsson,
software
technology,
a
developer
in
cicd
infrastructure
areas
and
lately
looking
into
software
supply
chain
aspects
based
in
stockholm,
sweden.
So
that's
me
and
interoperability
is
like
one
of
the
areas
I
spent
years.
So
it's
like
kind
of.
C
Yeah
you
work
for
erickson
and
shopping
working
in
with
developer
ci
cd
have
half
of
my
time
working
with
open
source
things
both
here
and
interoperability,
but
also
the
zig
events,
the
cd1
products
and
also
a
full
product
and
other
times
it's
internal.
As
yes,.
H
I
guess
that
leaves
me:
I'm
known
in
the
real
world
is
jeremy
stanley,
I'm
one
of
the
systems
administrators
for
the
open,
dev
collaboratory
and
the
maintainer
on
the
zuul
project.
Gating
ci
cd
system.
A
Great
I'm
kara
mark
I
work
at
the
cdf
and
co-chair
of
the
sig.
A
I
guess
having
said
that,
I'll
say
that
fatty
is
stepping
down
as
kosher
fatty's
the
best
coaches
ever.
So
I'm
very,
very,
very
sad,
but
we
are
looking
for
another
one
and
we
have
some
people
interested
so
yeah
yeah
great.
So
look
forward
to
that.
A
That
should
be
good
and
we
have
anders
here
today
to
present
to
us,
but
before
we
get
to
that,
what
we'll
just
quickly
go
over
some
of
our.
A
D
A
Okay,
that's
absolutely
fine!
You
don't
have
to
do
yeah
because
I
I
said
to
you
just
come
come
discuss
with
us.
It's
not
yeah.
D
Yeah,
that's
pretty
much
what
I
was
prepared
for
now,
but
but
if,
if
you
want
a
presentation
like
I'd,
be
happy
to
to
give
you
one
at
a
later
date.
A
Okay,
that's
fine!
We
won't.
We
won't
worry
about
that
at
all.
Today
I
mean
the
presentation:
we're
just
really
happy
to
have
you
here
and
to
discuss
quality
gates
with
us
justin.
Do
you
want
to
start
the
conversation
since
you
you
raised
it
and
you
created
the
issue
as
well.
G
So
these
are
the
ones
that
ebay
does
and
during
the
build
we
check
for
cpes
in
in
the
dependencies
we
see,
do
unit
tests,
contract
tests
and
then
like
code
quality
gates
and
code
quality
checks
are
a
soft
gate.
They're
like
a
hey,
don't
don't
merge
this
pr?
It's
got
tons
of
bugs
and
not
a
you
may
not
deploy.
G
Then
we
deploy
to
a
temporary
environment
and
run
end-to-end
tests
against
it.
Push
to
a
staging
server.
That's
a
shared
resource
across
ebay
that
many
people
depend
on
and
repeat,
and
then
we
do
a
prod
deploy.
A
G
I
would
consider
all
of
those
yeah
all
of
those
to
be
quality
gates:
okay,
possible
exception
of
qual
quality
checks
for
code.
That's
a
soft
gate
might
just.
B
Yeah,
as
I
noted
in
the
last
paragraph,
I
think
this
is
like
a
mix
of
various
things.
I've
seen
in
various
communities-
and
I
also
like
seeing
used
by
my
colleagues
and
the
difference.
B
B
Let's
look
at
it:
yeah
some
production,
type
of
checks,
release
checks
and
so
on
and
again
like,
even
though
everyone
is
focused
on
security
and
speed
and
those
things
there
are
things
that
takes
longer
time
to
run
like
established,
robustness,
characteristics,
type
of
tests
and
they
are
kind
of
on
the
right
hand,
side
with
hand
side
of
the
flow
because
they
take
ages,
and
sometimes
you
can't
do
much
about
them,
because
you
have
regulatory
requirements
which
you
must
run
entitle,
for
example,
traffic
for
48
hours
before
you
can
consider
that,
as
you
know,
eligible
for
release,
for
example,
and
one
thing
tan
highlighted
there,
which
is
something
I
missed,
and
I
don't
know
how
I
missed
it,
especially
an
opening
open,
improv
community.
B
There
is
a
check
before
the
commit
gets
merged,
doing
some
kind
of
speculative
merging
to
make
sure
whatever
ends
up
being
merged
on
the
main
development
branch
actually
works
in
a
way
they
are
merged
or
they're
like
merged,
and
this
is
coming
from
zul
project
like
this
speculative
merging
and
jeremy
is
here.
I
shouldn't
talk
more
about
those
things
that
I
don't
know
yeah
much
about
yeah.
H
I
I
I
can
elaborate
on
that
a
little
bit,
but
basically
the
the
design
of
the
project
gating
system
that
that
we
write
is
it's.
It's
focused
on
preventing
errors
from
getting
into
the
trunk
of
your
revision
control
system.
So
our
our
view
on
this
is
that
you
should
never
allow
errors
to
merge
in
the
first
place
that
the
testing
things
post,
merge
is
kind
of
a
waste
because
you
wind
up
with
developers,
pointing
fingers
at
each
other,
arguing
whose
fault
it
is.
Nobody
gets
around
to
fixing
things
or
they're
forever.
H
So
so
we
basically
don't
consider
there
to
be
soft
and
hard
gates.
All
gates
are
gates
that
prevent
changes
from
being
allowed
to
ever
merge
and
we
enforce
that
by
having
the
project
gating
system
be
the
only
thing
that's
allowed
to
merge
changes.
So
people
don't
merge
changes
to
get
repositories.
People
propose
changes,
people
review
changes,
people
approve
changes,
but
the
gating
system
is
what
decides
that
the
change
will
or
won't
merge,
and
in
order
to
avoid
deadlocks,
it
borrows
a
concept
from
processor
design,
the
idea
of
speculative
execution
and
pipelines.
H
So
it
tests
all
of
the
changes
serialized
in
the
order
in
which
they
got
approved,
but
it
parallelizes
all
of
the
testing
so
that
it
can
not
have
to
wait
for
all
the
tests
for
one
change
to
complete
before
the
next
changes
started
testing
and
then,
if,
for
some
reason,
a
proposed
and
approved
change
fails
testing,
then
it's
removed
from
the
sequence
and
all
the
changes
that
were
see
sequenced
behind
it,
get
their
testing
restarted
so
that
we
don't
waste
test
resources
for
things
unnecessarily
but
yeah.
That's
that's
the
basic
idea
behind
the
project.
H
D
All
right
all
right
yeah,
so
I
tried
to
add
some
items
to
to
the
to
the
existing
bullet
points
here.
Given
like
how
old
buys
it's
got
in
case,
people
are
aren't
familiar
with
what
the
open
policy
agent
is.
It's
a
it's
a
general
purpose
policy
ending,
so
you're
gonna
provided
policies,
and
then
you
can
query
oppa
for
decisions,
so
you
can.
D
This
is
commonly
used
for
things
like
authorization
where
you
say
like
okay,
any
doctor
should
be
able
to
you
know
to
see
the
medical
records
of
their
patients,
but
only
on
only
of
their
own
patients,
and
only
when
on
duty
or
so
on.
D
So
so
that
would
be
an
example
of
a
policy
and
and
of
course,
like
policy
is
a
pretty
it's
a
pretty
generic
term
and
that's
what
we
kind
of
try
and
take
advantage
of
when
building
oppa,
so
that
you
can
use
one
technology
and
one
policy
language
to
describe
policy
in
pretty
much
any
kind
of
field,
so
so
yeah.
D
One
of
those
fields
is,
of
course,
like
ci,
cd
and
deployments,
and
building
deployment
pipelines
where
you
might
wanna
have
like
policy
determine
determine
whether
a
bill
or
a
deployment
should
be
allowed
or
not
or
or
if
there's
like
additional
obligations
and
so
on
so
yeah.
So
that's
kind
of
the
angle
from
which
I
see
things
and
yeah.
So
so
I
just
added
some
things
here
where
we
see
like
oppa
being
used
in
in
this
context
and
again
cara
I'd,
be
happy
to
to
give
a
more
like
formal
presentation.
D
At
some
point
I
I
talked,
I
think
it
was
in
june
or
so
last
year
presented
someone
oppa
and
I'd
be
happy
to
do
that
again.
But
of
course,
some
common
things.
We
see
policies
written
for
it's
like
application,
misconfiguration
things
like
that.
You
can't
like
deploy
a
crazy
amount
or
replicas
for
your
service,
that
you
don't
run
your
containers
as
root.
D
D
D
So
the
kind
of
same
rules,
the
same
tool
applies,
the
same
rule
applies,
so
that's
another
common
thing
to
do
like
make
sure
that
you
don't
expose
your,
I
don't
know,
s3
buckets
to
the
public,
ensure
you
don't
run
on
like
instant
instance,
types
that
aren't
like
appropriate
for
for
your
application
and
any
type
of
security
configuration
like
firewalls
and
so
on,
and
then
there's
yeah.
Another
classic
kind
of
topic
for
heated
debate
is,
of
course
this
and-
and
I
added
it
more
more
or
less
for
fun.
D
This
kind
of
deployment
windows
like
should
you
deploy
on
fridays
or
not
so
I'm
sure
that's
been
a
hot
topic
in
the
in
this
cd
foundation.
Before
it
it's
something.
That's
it's
a
bit
of
a
yeah,
it's
it.
It
usually
sparks
like
a
debate
but
but
ignoring
like
the
friday
discussion
or
not,
but
more
fine-grained
things
like
yeah.
D
You
can
deploy
whenever
you
want
as
long
as
there's
like
someone
on
call
to
to
initiate
a
rollback,
if,
if
that's
what's
going
to
be
needed,
maybe
not
push
like
your
most
experimental
feature
on
black
friday
and
so
on,
and
then
of
course,
there's
organizational
policies
and
requirements,
simple
things
like
requiring
that
any
resource
deployed,
whether
it's
an
application
or
if
it's
infrastructure
that
it's
properly
labeled
so
there's
a
team
owning
the
resource.
D
There
might
be
a
call
center,
a
department
and
so
on.
So
that's
so
that
we
can
kind
of
make
it
make
an
inventory
of
of
any
resources
deployed.
D
Kubernetes
mission
control,
of
course,
that's
kind
of
attaches.
It's
it's
more
or
less
just
one
way
of
deploying
things.
So
it's
kind
of,
I
think,
it's
kind
of
mentioned
in
in
implicitly
in
a
lot
of
these
other
points,
so
I'm
not
gonna,
not
gonna
dab
on
that
today,
but
impact
analysis.
I
think
that's
another
kind
of
interesting
type
of
policy.
I
was
seeing
a
lot
of
or
not
a
lot,
but
things
like
infra
cost,
where
you
have
a
policy
determined
or
a
policy
say
that
you
can
you
can't
deploy
resource?
D
You
can
redeploy
resources
up
to
like
a
certain
amount
of
dollars,
but
if,
if
it
exceeds
that
you're
gonna
need
like
approval
from
management
or
yeah,
maybe
a
colleague
at
least
the
blast
radius.
Another
thing
like
you
might,
you
might
think
it's
safe
to
delete
an
unused
namespace,
but
if
it
turns
out
like
there's
200
services
running
in
that
namespace-
and
you
might
be
alerted
by
that
fact
and
want
to
investigate-
what's
that
about
before
you
do
that
deletion.
D
So
so
that's
another
interesting
kind
of
policy
and
yeah
last
it's
kind
of
a
meta
category-
and
I
think
I
mentioned
it
in
in
june
when
I
talked
here
as
well
and
that's
policy
to
kind
of
to
govern
the
build
and
deployment
pipelines
themselves,
and
I
think
I've
seen
a
few
examples
of
these
of
this
recently,
where
you
have
teams-
and
I
think,
like
with
things
like
github
actions,
where
your
deployment
or
building
deployments
by
configuration
is
part
of
of
your
actual,
like
application
code,
and
it's
gonna
attach
to
that.
D
So
the
team,
the
team
any
team
can
just
like
they
can
configure
their
builds
and
deployments.
However,
they
wish,
which
is
good,
like
we
want
team
autonomy
and
so
on,
but
we
might
still
want
to
require
certain
organizational
rules.
D
Things
like
we
might
want
to
ensure
that
you
can't
you
can't
deploy
a
build
configuration
without
having
like
a
unit
test
task
or
without
running
linters,
so
on
so
it's
kind
of
rules
on
the
rules.
D
So
it's
pretty
meta,
but
I
think
it
it
makes
it
certainly
makes
sense
those
kind
of
rules
as
well
yeah.
So
that's
a
a
couple
of
examples
of
kind
of
oppa
being
used
for
for
quality
gates
and
and
yeah
in
this
domain.
D
What
kubernetes
mission
control
is
okay,
yeah,
good
question
so
like
kubernetes
is
basically
just
an
api
to
manage
state
in
the
fcd
database.
So
anything
you
do
in
kubernetes
whether
it's
a
deployment,
it's
a
new
service,
it's
pretty
much
much
an
api
on
top
of
a
database,
so
at
any
and
any
operations
to
kind
of
update,
create
or
update
the
state
of
that
database
has
to
go
through
the
kubernetes
api.
D
So
when
you
say
like
create
a
new
deployment
in
this
namespace,
you
gonna
ask
the
kubernetes
api
to
do
that,
so
the
kubernetes
admission
control.
It's
it's
one!
Module
in
that
api
that
looks
at
the
resource
about
to
be
deployed
and
then
determines
whether
that
should
be
allowed
or
not.
D
If
you
talk
about
things
like
authorization,
that's
largely
based
on
like
who
you
are
and
what
you
are
entitled
to
do,
based
on
your
roles
and
and
factors
like
that,
while
in
admission
control,
we
we've
already
passed
the
stage
of
authorization,
we
know
who
you
are
and
you
are
authorized
to
do
this.
But
at
admission
control
stage
we
look
at
the
actual
resource,
so
that's
where
we
can
say
like
okay,
you
can,
you
can
deploy.
D
Any
deployment
needs
to
have
at
least
two
replicas
and
if
it
doesn't
we're
gonna
we're
gonna
deny
this
deployment
and
any
any
new
service
needs
to
have
needs
to
be
in
this
or
that
namespace.
It
needs
to
be
labeled
with
your
team
name
and
so
on.
So
it's
kind
of
a
it's
kind
of
a
gatekeeper
for
the
kubernetes
api
and
and
the
the
old
implementation
for
kubernetes
admission
control
is
appropriately
named
gatekeeper
as
well.
So.
A
I
have
more
questions
on
that.
Actually,
when
you
speak
of
drift
control,
is
this
specifically
related
to
people
changing
like
super
admins,
making
runtime
changes
and
not
doing
this
through
deployments
or
some
sort
of
get
up
space
changes.
D
No,
I
think,
like
in
many
organizations
like
kubernetes
admission
control,
that's
where
you
that's,
where
the
kind
of
deployment
checks
are
like.
That's
that's
where
you
put
the
controls
and
the
policy
rules,
and
then
you
have
commonly
have
some
way
of
kind
of
replicating
that
in
your
local
environment.
D
So
you
don't
need
to
kind
of
deploy
things
before
knowing
like
this
isn't
going
to
fly,
because
it's
it's
a
violation
of
policy,
but
I
think
in
in
many
deployment
systems
where
for
like
kubernetes
organizations,
that's
where
that's
where
the
checks
are
done.
So
so
you
can
do
some
static
analysis
at
the
build
stage
and
then
you
just
deploy
it
and
have
the
kubernetes
admission
controller.
Tell
you
whether
that
was
allowed
or
not.
G
It
is
yeah,
it
is
okay,
one
of
the
things
that
we're
we're
working
on
right
now.
I'm
not
sure
that
I
would
call
this
quite
a
quality
gate,
but
is
translations
in
the
pipeline,
so
ebay
is
an
international
website
and
most
of
our
people
don't
speak
all
of
the
languages
that
ebay
operates
it.
So
often
we
will
write
strings
in
english
and
need
to
build.
G
Basically,
we
write
the
strings
in
english
and
commit
them
put
it
up
for
pull
request,
and
then
it
just
sits
there
and
waits
while
translators
do
their
thing,
and
that
takes
a
few
days,
which
is
a
bummer,
and
so
the
thing
that
we're
currently
in
the
process
of
doing
is
subbing
in
machine
translations
for
a
short
term.
While
we
basically
file
an
asynchronous
to-do
for
the
translation
team.
G
To
like,
please
provide
us
with
the
correct
translations
for
these
or
validate
these
machine
translations,
and
I
I
don't
have
a
word
for
what
that
is,
what
that.
What
that
process
is.
G
D
A
So
how
many
of
these
quality
gates
will
relate
to
things
like
checking
your
dependencies
doing
dependency
analysis.
G
We
have
some
of
that.
It's
primarily
around
build
materials,
validation
against
known
cves.
G
We
don't
have
things
like
license
checks
or
anything
like
that
in
the
pipeline
currently,
and
even
that
cve
checking
is
work
in
progress
and
so
we're
not
doing
a
ton
of
that
kind
of
validation.
Yet.
A
E
A
A
A
E
So
that
would
be
something
I've
seen
in
the
past,
not
not
so
much
now,
but
I've
definitely
been
on
teams
where
we
actually
go
through
testing
the
rollback
process
as
well.
E
E
A
And
anders
when,
when
these
different
quality
gates,
when
they
are
triggered,
do
what
do
you?
What
are
you
seeing?
Are
people
just
blocking
it?
Are
they
putting
a
yellow
flag
on
it
or
what
is
the
response.
D
D
D
This
isn't
gonna
work
because
we're
gonna
we're
gonna
need
to
upgrade
some
system
here
so
making
this
kind
of
resource
type
like
deprecated
or
or
removed
so
like
for
things
like
that
issue
warnings,
but
for
anything
else,
it's
it's
just
easier
to
deny
and
have
people
update
your
deployments,
configuration
or
resource
descriptions
and
then
have
them
redeployed.
D
But
I
think
one
thing
that's
like
really
important
to
stress
here
with
regards
to
like
oppa
and
and
and
really
like
policy
as
code
and
and
like
a
huge
advantage
of
of
creating
policy
as
code
is,
of
course,
that
if
you
disagree
with
one
of
these
rules
like-
and
you
are
a
developer
like
these
rules
are
just
cold
and
that's
like
that's
what
you're
working
with
so
so
you
so,
ideally
it's
not
like
you
need
to
like
pick
up
the
phone
or
walk
over
to
the
other
side
of
the
office
to
the
ops,
people
or
or
so
like.
D
These
rules
should
be
like
available
for
anyone
to.
So
if
you
want
to
make
a
change
you
want
to,
if
you,
if
you
think
like
having,
I
don't
know
six
replicas
as
a
max
limit
is
way
too
low.
Like
then,
you
submit
a
pr
and
you
to
kind
of
have
that
raised
and
and
any
discussion
around
that
rule
is
then
like
kind
of
kept
to
a
pr
so
and
and
and
that
discussion
can
of
course,
then
be
like
traced
or
seen
by
others,
and
others
can
chip
in
and
so
on.
D
So
it's
kind
of
an
idea
is
to
kind
of
democratize
this
the
whole
policy
process
which
it's
like
in
any
like
environment,
where
I
used
to
work.
It
was
always
like
some
other
team,
like
a
security
team,
where
I
didn't
know
any
of
those
names
and
like
they
were
so
far
away
in
the
organization,
so
it
was
pretty
intimidating.
It
was
super
time
consuming
and
it
was
just
a
big
like
train
of
like
energy,
to
kind
of
try
and
have
anything
changed
so
so
yeah.
D
D
For
sure
for
sure,
yeah
yeah-
and
I
think
it
empowers
like
the
security
team
as
well-
it's
not
like
we
ignore
them
now,
like
it's,
not
it's
not
a
way
to
like
sidetrack
them.
It's
it's
it's
in
power,
because
they
they
too
aren't.
They
really
aren't
interested
in
having
like
these
these
walls
around
their
policies
they
want
to.
They
want
to
have
developers
and
people
around
them
engaged
in
this
as
well,
even
if
they
might
still
have
the
final
say,
but
I
think
it's
it's
for
the
benefit
of
everyone.
A
Yeah,
which
actually
I
mean
justin,
was
was
interested
in
both
cataloging
quality
gates,
but
also
giving
a
sense
of
what
are
best
practices,
and
this
is
actually
a
really.
I
would
think
very
important
point
for
best
practices
that
developers
and
teams
really
have
a
clear
insight
and
a
clear
sigh
in
the
policy
and
an
open
discussion.
G
Yeah,
I
think
I
think
this
policy
stuff
is
super
important.
It
makes
it
so
there's
like
a
couple
pieces
of
this.
G
Like
one
is
when
I'm
designing
my
pipeline,
I
would
love
to
have
little
blocks
that
I
can
click
into
place
and
say
like
yes,
I
will
take
test
validation
and
I
will
take
load
tests
here
and
I
will
take
you
know:
validation
of
machine
translations
or
whatever,
and
then
secondarily
from
like
an
infrastructure
standpoint,
I
would
love
to
say:
oh
wait,
you
you're
doing
things
where
you're
limiting
you're
limiting
how
much
money
someone
can
spend
on
infrastructure
until
they
have
prior
approval.
Well,
I
didn't
think
of
that.
G
I
think
it's
a.
I
think
it's
a
important
thing
around
discovery,
because
until
I
worked
for
a
global
corp,
I
didn't
know
about
all
these
cool
quality
gates
that
they
have
full-time
engineers
to
go
build
like
when
I
worked
at
amazon.
G
E
E
H
Yeah
one
of
the
biggest
innovations
for
our
deployments
and
the
open
dev
collaboratory
has
been
that
we
worked
out
a
way
to
effectively
deploy
ephemeral,
copies
of
subsets
of
our
infrastructure
and
then
perform
integration
tests
between
those
services.
So
so
even
our
configuration
management
and
our
our
deployment
orchestration
are
tested
that
way
to
make
sure
that
a
changing
configuration
isn't
going
to
mess
up
production
because
we.
A
No
no
go
ahead.
I
was
just
asking
for
your
opinion,
but
please
please
go
back
to
being
a
good
parent.
A
G
Yeah,
I
think
I
think
I
still
think
the
value
and
kind
of
quant
and
cataloging
some
of
these
techniques,
I'm
not
entirely
sure
where
that
lives,
but
having
a
having
a
grab
bag
of
like
ideas
for
how
you
could
build
a
pipeline
sounds.
G
A
G
So,
like
you
know
how,
in
our
like
landscape
views,
we
have
a
bunch
of
like
here
are
the
infrastructure
that
you
could
be
using
and
you're
like
okay.
Well,
I
did.
I
didn't
need
that
so
I'll
go
look
through
these
six
projects,
I'm
thinking
of
something
that's
more
like
that,
but
for
techniques
I
was
like
cool.
I
have
techton
now
what
about
like?
G
G
G
A
Yeah
we
at
the
cdf
we're
creating
best
practices,
so
the
best
practices
sig
is
actually
working
on
its
own
entire
set
of
these
sort
of
things.
It
sounds
like
a
very
related
to
that,
which
is
great,
because
actually
we
could
work
on
the
quality
gates
here
and
then
contribute
it
to
the
best
practices,
sake
and
sort
of
see
how
it
fits
in
with
what
they're
doing
as
well,
and
they
have
a
start
of
like
a
hugo
site.
I
G
I
G
A
Yeah
the
event
sig
is
actually
doing
a
lot
around
vocabulary
for
cd
events,
a
sort
of
groundwork
for
for
city
events.
So
that's
been
really
interesting,
actually
and
really
useful
to
see
how
different
tools
are
or
different
groups
like
teams,
we
use
different
nomenclature.
A
Yeah
the
the
question
on
quality
gates
immediately
came
up
at
another
meeting.
I
mentioned
it
to
oleg
and
he
was
like.
Oh
this
comment.
You
know,
captain
is
reviewing
the
term
like.
I
think
that
that
term
actually
came
from
captain
or
you
know
they
were
one
of
the
first
users
of
it
and
it's
like
a
commonly
understood
term,
but
apparently
it's
under
review
with
them.
So
it's
interesting
how
different
different
tools
and
teams
will
use
different
words
to
describe
very
similar
things
and
then
also
how
words
themselves
come
in
another
fashion.
B
A
question
actually
like
just
when
you
mentioned
kyra,
I
think
ann
mary
started
this
pipeline
step
and
stage
time.
Energy
work,
interoperability
and
those
pr's
are
still
open.
I
the
prs,
don't
say
like
gates
and
so
on,
but
some
of
those
things
she
started
working
there
like
are
in
our
gates,
as
they
like
build
gate.
She
has
a
build
stage
there.
So
I
don't
know
like
how
let
me
put
two
links
to.
B
A
B
B
B
G
State
like
like
production,
release
and
they're
like
the
big
chunks
of
the
pipeline
and
then
this
step
terminology
is
like
a
quality.
Gate
is
made
up
of
steps,
and
so
you
might
have
like
a
an
step
and
then
you
might
provision
something.
G
G
E
A
tough
one,
too,
steps
imply
to
me,
you
know
sequential
activities
and
our
you
know.
The
quality
gates
may
not
necessarily
be
in
a
certain
order
or
may
be
composed
of
steps
at
the
beginning
and
at
the
end
you
know
in
order
to
encompass
a
an
idea
so
yeah,
how
do
how
would
we
categorize
our
quality
gates?
Would
they
be?
E
G
Them
imply
location,
they
imply
stages
like
you're,
not
going
to
run
a
load
test
during
your
build
stage,
you're
going
to
wait
until
it's
deployed
somewhere
and
you're,
probably
not
going
to
run
your
unit
tests
after
on
your
prod,
deploy,
I'm
going
to
do
that
earlier.
E
G
A
Okay,
just
to
quickly
wrap
up
because
we
are
we
are
running
out
of
time.
Do
we
have
any
last
questions
or
anything
to
ask
of
andrew
since
he's
here
with
us
today,
you're
welcome
to
come
back
anytime.
You
want
as
well.
D
Thanks
great
to
be
here,
yeah,
let's,
let's
schedule
like
a
more
like
of
a
presentation
or
demo,
like
you
know,
in
a
month
or
two,
if
you're
interested.
A
Yeah
sounds
great.
That
sounds
really
good.
Okay,
I'll
I'll
I'll
be
in
touch
with
you
for
that
I'll,
put
an
action
item
for
me,
the
last
just
quickly
before
we
wrap
up
the
cfb
for
cdcon
ends
tomorrow
midnight.
It
might
be
midnight
us
time
on
that
page.
It
gives
you
the
exact
time,
but
please
please
do
submit
if
you
haven't
yet
submitted.
We
do
want
all
your
talks,
especially
on
interoperability.
A
It
would
be
great
to
see
you
at
cdcon,
so
you
here's
just
some
more
information
on
cd
events
which
is
going
up
pace.
I
bring
it
up
here
because
I
feel
like
there's
a
ton
of
overlap,
cd
events,
kind
of
the
events
they
kind
of
grew
out
of
this
one
and
and
we're
all
working
very
same
space,
for
example
on
the
vocabulary.
A
So
please
do
look
at
what
they're
the
cd
events
that
they're
building
out,
because
it
should
be
a
really
good
project,
it's
quite
exciting,
trying
to
get
more
and
more
interoperability
and
ci
cd.
So
it's
very
good
to
that
point.
Also
we're
going
to
have
a
full
day
at
kubecon
on
cd
events
and
we're
working
out
the
schedule
right
now
so
it'll
be
sort
of
a
combination
between
talks
and
more
hands-on,
workshopping,
probably
but
that's
being
worked
out.
A
So
if
you
are
at
kubecon
free
one
day
event,
please
do
join
us.
It
would
be
great
to
see
you
there
as
well
and
we've
had
our
discussion.
So
that
was
all
my
my
sort
of
reminders
for
you
all.
I
guess
and
calls
to
get
more
involved.
But
if
you
have
any
questions
on
any
of
that,
please
don't
hesitate
to
ask
now
or
ping
me.
A
Good
all
right,
thank
you
all
very
much
and
thank
you
especially
to
enders
for
for
coming
and
discussing
with
us
that
was
really
awesome.
I
certainly
learned
more
about
quality
gates
than
I
knew
so.
Thank
you.
It's
a
really
good
discussion,
thanks
justin
for
kicking
it
off.