►
From YouTube: SIG Interoperability Meeting - Mar 17, 2022
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
A
B
A
A
We'll
just
wait
a
couple
more
minutes
to
get
a
few
other
others
to
join.
That
might
be
interested
and,
of
course,
these
are
all
recorded,
so
we'll
post
this
afterwards
as
well.
So
anyone
who
missed
the
presentation
can
go
back
and
look.
A
We'll
get
started
here
in
a
bit:
cara
had
was
double
booked
today,
so
I'm
running
things
today.
A
A
A
Well,
let's,
let's
go
ahead
and
get
started.
I
know
you
know
we
all
have
our
day.
We
want
to
get
to.
The
one
thing
I
do
want
to
mention
before
mike
presents
today
on
open
feature
is
just
that
we
need
to
change
our
meeting
time
because
half
you
know
most
of
the
world
is
now
on
a
different
time
zone
and
I
guess
normally
we
hold
this
at
1
500
utc
in
the
summer.
A
So
next
time
I
just
got
admin
privileges
on
the
public
calendar,
so
I'll
make
sure
that
gets
changed
on
the
public
calendar
and
so
that
you
can
add
those
other
than
that.
Let's
go
ahead
and
move
on
to
mike's
presentation.
B
All
right,
perfect,
thank
you.
Let
me
go
ahead
and
share
my
screen
all
right.
Well,
I
appreciate
the
invite
today
nice
to
meet
everyone.
I'm
mike,
I
work
at
dynatrace,
I'm
in
the
detroit
area
and
we
just
kicked
off
a
new
initiative
called
open
feature.
So
it's
we're
basically
just
laying
the
initial
foundation
here,
but
the
idea
is
trying
to
make
feature
flagging
more
available
to
everyone,
basically
by
more
or
less
commoditizing
the
the
sdk
portion
of
it
and
making
it.
B
So
it's
really
easy
to
get
started
and
I'll
kind
of
show
you
how
we're
hoping
to
do
that.
B
So
if,
if
you're
familiar
with
open
telemetry,
it's
a
extremely
popular
project,
part
of
the
cncf
right
now
and
they
they
basically
do
the
same
thing
but
for
observability
data
they
made
it
so
the
community
came
together,
built
a
specification
and
then
released
sdks
around
observability
collection
across
a
huge
array
of
technologies.
B
B
We
also
wanted
to
provide
a
developer
first
cloud
native
implementation,
so
what
I
mean
by
that
is
is
basically
like.
If
you
think
about
a
traditional
like
feature
flag
life
cycle
right
now,
you
either
have
to
build
your
own
solution
or
go
direct
directly
to
a
vendor,
and
then
that
would
definitely
create
some
code.
You
know
vendor
lock-in
effectively
at
the
code
level.
B
What
we
wanted
to
do
is
have
you
know,
kind
of
a
vendor
agnostic,
sdk
and
if
you
happen
to
be
in
the
kubernetes
world,
we'll
provide
an
operator
that
can
handle
a
lot
of
the
heavy
lifting
behind
the
scenes
for
you,
so
you'd
be
able
to
really
test
out
how
feature
flagging
could
work
with
very
low
barrier
of
entry.
But
of
course
it
would
be
great
if
we
took
you
know
the
open,
telemetry
model
here,
where
it's
we
have
a
very
good
feature
set.
You
can
get
started.
B
You
can
understand
the
value
of
feature
flagging,
but
as
soon
as
you
start
needed
to
get
getting
into
things
like,
maybe
audit,
logs
and
other
more
kind
of
enterprise
features,
we'd
have
a
path
for
offering
commercial
offerings
here,
so
any
vendor
would
be
able
to
basically
tie
into
the
system,
and
I
can
show
an
example
of
that
in
a
few
minutes.
But
the
idea,
basically
is
you:
could
you
know,
provide
an
upgrade
path,
essentially
from
the
open
source?
B
Right
now
we
looked
at
the
current
ecosystem
in
future
flags
and
and
really
there's
a
lot
of
sdks
that
are
effectively
doing
the
same
thing.
We
actually
have
quite
a
few
vendors
on
board
already,
and
that
was
their
comments
as
well
they're.
If
you
look
at
it
I
mean
fundamentally,
they
do
basically
the
same
thing
so
there's
a
lot
of
you
know,
essentially
wasted
effort
and
building
the
same
thing
across
companies
they're.
B
Also,
almost
all
of
them
are
open
source,
so
you
can
look
through
them
right
now,
but
they're
basically
maintained
just
by
the
vendor
themselves.
I
mentioned
this
earlier,
but
we
really
see
vendor
lock-in
at
the
code
level
is
is
a
bit
of
an
issue
here.
B
It
would
be
one
people
would
be
a
little
reluctant
to
modify
their
code.
You
know
basically
across
the
entire
code
base,
with
with
specific
you
know,
vendors
in
mind,
just
in
case
they
ever
had
to
switch
for
whatever
reason
makes
it
a
much
trickier
topic
to
migrate
to
other
providers
based
on
you
know,
changing
use
cases
and
needs
also
they're,
not
really
using
cloud
native
capabilities
I'll
get
into
that
in
just
a
little
bit
and
then
for
from
dynatrace's
perspective.
A
B
B
B
This
would
make
it
much
much
easier
to
you
know,
have
a
single
entry
point
for
developers
that
could
use
basically
any
backend
system.
We
wanted
to
build
a
vendor
agnostic
sdk,
so
this
will
be.
Probably
our
main
focus
for
the
the
next
few
months
is
is
releasing
something
that
would
be
the
primary
entry
point
for
developers
and
then
the
back
end
like
flag
evaluation.
Logic
would
be
up
to
basically
we're
calling
it
a
provider,
but
it
basically
be
the
backend
provider
that
you
register
would
be
the
one
responsible
for
the
evaluation
logic.
B
We
want
to
natively
support
open
telemetry,
so
that
really
ties
nicely
into
the
cncf
but
enhancing
distributed
traces.
There's
a
lot
of
interesting
opportunities
around
collecting,
metrics
and
then
correlating
that
with
flag
evaluations,
and
then
they
are
also.
It
would
provide
us
the
opportunity
to
do
request,
scope
context.
So
if
you
look
at
examples
of
of
feature
flag
management
systems,
almost
all
of
them
are
driven
off
of
context,
so
you'd
pass
in
some
metadata
to
a
flag
evaluation
and
try
to
determine,
and
that
would
be
used
to
make
the
flag
evaluation
decision.
B
So
what
we
could
do
here
is
we
could
attach
metadata
to
the
request
and
downstream
services
could
use
that
metadata
in
their
flag.
You
know
decisions
so
there's
some
pretty
interesting
opportunities
there.
B
We
also
wanted
to
provide
a
kubernetes,
focused
implementation,
and
that
would
allow
people
to
really,
if
you're
in
the
kubernetes
world,
to
experiment
with
feature
flags
incredibly
easily,
so
at
a
really
really
really
high
level.
This
was
our
proposed
kubernetes
native
architecture
effectively.
The
interesting
part
here
would
be
to
inject
a
sidecar
process
that
would
handle
the
flag
evaluation
and
that
would
allow
us
to
keep
the
sdks
incredibly
light
and
not
have
to
do
any
of
the
flag
evaluation
logic.
B
In
each
library
we
could
have
a
standard
flag
evaluation
process
that
would
handle
the
actual
evaluation
logic.
In
this
example,
we're
also
looking
at
potentially
using
a
custom
resource
definition
in
kubernetes
to
define
the
flags
themselves
which
would
allow
us
to
just
tap
into
like
the
existing
s
etd.
You
know,
data
store
for
storing
the
the
flags
that
would
just
be
for
the
kubernetes
native
piece.
B
B
The
the
people
involved
in
open
feature
right
now
are
discussing
different
topics
on
there.
I'm
also
doing
some
community
outreach
to
to
find
vendors
in
the
space
and
other
you
know,
people
that
are
interested
trying
to
get
as
much
feedback
as
possible.
I
think
it's,
it's
extremely
important
to
have
a
solid
spec,
because
it's
pretty
difficult
to
change
once
we,
we
kind
of
lock
that
into
version
one.
So
a
lot.
B
A
lot
of
time
and
energy
has
gone
into
the
research
at
this
point
and
it
really
hasn't
translated
into
a
spec
at
this
point.
But
I
think
that's
going
to
be
happening
in
the
next
few
weeks,
so
if
this
is
an
area
of
interest,
I
would
certainly
encourage
you
to
join
sooner
than
later,
so
you
can
help
define
the
spec
in
terms
of
milestones,
so
we're
basically
right
here
in
the
the
mission,
governance,
vision,
initial
scope
and
architecture
state.
B
We
have
quite
a
few
people
on
board
or
have
declared
interest
already,
which
is
great
and
I've
been
meeting
with
a
number
of
different.
You
know
groups
organizations
companies
just
to
try
to
let
them
know
what
we're
working
on
invite
them
to
participate.
B
We're
really
hoping
to
have
some
kind
of
alpha
release,
so
we
can
show
how
it
works
at
kubecon,
eu
and
hopefully
that
can
really
help
solve
some
of
the
visions
that
we're
we
have
in
mind
the
august
one
is
kind
of
arbitrary
honestly.
I
think
I
just
had
to
fill
the
gap
on
the
chart
here,
but
basically
we
also
want
to
make
sure
that
you
know
observability
is
a
first-class
citizen
as
part
of
this
and
then
we're
really
hoping
to
have
something
that
we
can.
B
You
know
kind
of
analysis
like
a
ga
or
1.0
release
at
kubecon
us,
which
happens
to
be
in
detroit,
which
is
really
close
to
my
house,
so
pretty
exciting
opportunity,
I'd
say
to
attend
the
event
and
announce
something
cool
yeah,
so
yeah
we
are
still
in
kind
of
the
the
project
bootstrapping
phase.
So
it's
a
great
time.
If
you
have
any
interest
you
know
to
join,
we
did
apply
to
be
a
cncf
sandbox
project.
I'm
still
waiting
to
hear
back,
apparently
the
march
6th
time
where
they
were
supposed
to
talk
about
it.
B
They
ran
out
of
time,
so
we
kept
pumped
to
the
next
meeting.
Hopefully
we'll
hear
something
soon,
but
apparently
they've
already
been,
you
know,
kind
of
they
know
about
the
project.
So
hopefully
it's
a
pretty
easy.
You
know
process.
B
We
are
still
working
on
just
trying
to
get
as
many
people
involved
as
possible.
We
don't
want
this
to
be
like
a
dynastrace
thing.
It
should
really
be
a
community
thing
and
then
yeah
just
working
in
the
the
research
and
the
spec
itself
really
just
need
to
nail
down
the
spec.
B
We
want
to
get
that
proof
of
concept
out
as
soon
as
possible.
My
research
does
include
a
proof
of
concept,
but
I
think
we'd
want
to
have
something
that
users
themselves
could
try
out
so
that
that'd
be
a
short-term
goal
and
then
preparing
some
kind
of
public
announcement.
So
it's
not
it's
not
that
we're
keeping
it
secret,
but
it's
not
something
that
people
can
really
tangibly
use
at
the
moment.
So
it's
kind
of
been,
I
don't
know,
say
a
soft
launch,
so
cool.
B
If
you
are
interested,
we
have
a
very,
very
basic
web
page
available.
We
also
are
part
of
the
cncf
slack
channel.
You
can
find
us
under
open
feature,
there's
just
a
dedicated
channel
there
and
we
do
have
a
interested
party
page
that
you
could
open
a
pull
request,
for
it
doesn't
mean
that
you
have
to
be
terribly
involved.
It
just
shows
that
this
is
an
area
of
interest
for
you.
You
can
be
invited
to
the
community
meetings
and
you
know
we'd
certainly
love
to
get
your
feedback.
B
It
happens.
Every
two
weeks
is
our
community
meeting.
Sync,
and
here
is
a
handful
of
links.
I
can
share
this
presentation
with
you
as
well.
If
you
guys
have
you
know,
docs
or
something
that
we
can
associate
this
with,
but
yeah.
I
certainly
love
to
have
you
know
anyone,
so
that
is
basically
it.
If
there's
time
I
could
give
a
quick
demo
if
there's
not,
I
can
certainly
hand
it
back
to
you.
Listen.
B
Cool,
so
this
is
I'd,
say
hot
off
the
press
and
there's
a
lot
of
a
lot
of
discussion
happening
around
it
right
now,
but
I
I
do
think
it
does
a
decent
job
selling
our
end
goal.
B
If
we
look
here
basically
under
our
application
here,
so
this
is
just
an
incredibly
basic
rest
endpoint
and
in
this
case
it's
just
a
simple
get
request
with
a
message.
What
you
see
here
is
we
have
open
feature
and
at
the
moment
we're
we
have
a
method.
Name
is
enabled
with
a
flag
id.
So
it's
very
standard.
B
You
see
this
across
basically
any
feature
flag
system,
you'll
see
that
we're
registering
the
client
one
thing
you
may
notice,
if
you're
familiar
with
other
feature
flag
tools
that
we're
not
registering
like
we're,
not
passing
in,
like
an
api
token
or
any
kind
of
config
for
where,
like
the
the
flag
evaluation
occurs
I'll
get
into
that
in
a
second
but
to
kind
of
spoil
my
demo
to
some
extent
it's
because
we're
not
at
the
moment
we're
actually
not
registering
a
provider.
B
So
if
we
go
here-
and
I
run
the
no
op
demo,
it
basically
will
behave
with
the
default
value.
So
we
should
see
when
I
open
this
up,
that
we
are
getting
the
wrong
screen,
one
sec
there
we
go
so
welcome
to
the
api.
So
this
is
the
the
fallback
value
or
the
no
op
operation
here.
The
reason
that's
interesting
is
because
we
can
we
we
can
provide
a
provider
so
without
having
to
change
our
code
here.
So
that's
a
very
interesting
component
to
it.
B
So
now,
if
we
want
to
move
into-
let's
say
a
environment
variable
demo,
so
if
we
go
in
here,
let's
say:
here's.
Here's
our
feature
flag,
and
I
will
just
say
this
is
off
for
now
that
is
implemented
just
by
this.
The
logic
is,
is
extremely
basic,
but
you
can
see
that
we're
looking
at
environment
variables
on
the
system
and
if
it
happens
to
be
true,
it's
true.
Otherwise
it's
false.
So
let
me
just
start
the
demo
with
this
provider
and
what's
happening
here
kind
of
behind
the
scenes.
B
B
Wait
one
sec
and
we
refresh
you
get
exactly
what
you'd
expect
so
pretty
basic,
but
the
nice
part
is,
and
the
thing
to
highlight
is
you
did
not
have
to
change
your
code
in
order
to
change,
basically
the
back-end
provider
for
the
flag
evaluation
or
if
you
did,
and
you
happen
to
have
this
registration
in
your
code,
it
would
be
in
a
single
place.
You
wouldn't
have
to
go
change.
You
know
all
of
the
different
places
where
flags
were
being
evaluated
cool
on
to
the
next
one.
B
So
this
one
is
imagine
now
that
you
you
want
to
go
to
some
commercial
offering
for
future
flag
management
and
in
this
case
I'll
just
show
like
the
harness
one
there's
hundreds
of
fenders
it
seems
so
this
is
just
because
I
was
just
working
on
it.
That's
the
only
reason
I'm
picking
this
and
if
you
look
in
here
all
we're
doing
this
is
extremely
basic,
but
we
are
using
their
client
to
effectively
do
the
flag
evaluation
behind
the
scenes
if
we
were
to
go
into
I'm
going
to
pick
this
fibonacci
package.
B
So
this
is
this
is
like
going
the
scenario
where
maybe
you're
at
a
large
company,
where
different
teams
work
on
different
parts
of
the
code
and
then
maybe
you
share
it
across
services
in
this
case.
For
some
reason,
your
company
cares
about
generating
the
nth
digital
fibonacci
and
they
want
to
release
this
package
in
this
case
they're,
using
the
open
feature
and
they're
using
the
variant
options.
So,
instead
of
you
know
returning
a
boolean,
this
is
actually
a
string
value
and
we're
using
that
to
determine
which
algorithm
to
run.
B
B
This
is
another
interesting
part
too,
though
this
is,
I
ran
the
split
demo,
so
this
is
a
completely
different
vendor,
so
I
guess
we'll
pivot
and
use
the
split
one
instead,
but
it
still
works
exactly
the
same
so
that
it
just
you
can
basically
hot
swap
the
the
back
end
provider
in
this
case.
So
if
we
log
into
split
give
me
one
second.
B
B
Do
that,
but
hopefully
this
is
going
to
be
incredibly
fast-
this
algorithm
is
is
lightning
quick.
So
if
we
refresh
it,
it's
gonna
be
hard
to
tell,
but
it's
it's
done
already.
So
now,
if
we
go
look
at
how
this
could
be,
maybe
visualize.
So
now
that
we
we've
hooked
this
into
open
telemetry,
we
have
additional
information
on
a
distributed
trace.
If
we
go
into
zipkin,
I
can
actually
go
find
a
trace.
I
should
be
able
to
run
it.
We
can
see
that
we
have
a
fibonacci
call
here.
B
That
was
done
two
minutes
ago
that
took
4.3
seconds.
If
I
were
to
look
at
it,
we
would
see
a
span
here
that
has
the
flag
evaluation
and
we
can
see.
Split
was
the
provider
here.
Recursive
was
the
algorithm
that
was
run.
Fibonacci
was
the
client
library
that
was
run.
So
you
have
a
lot
of
information
here
to
actually
understand
why
this
call
took
so
long
now.
B
If
we
were
to
go
back
to
the
one
that
was
fast,
we
can
look
down
here
and
see
that
basically
this
was
this
was
the
reason
that
it
was
fast.
There
are
a
few
other
areas
of
interest
that
could
be
nice
to
kind
of
tie
into
this.
A
Any
questions
all
the
all
the
information
to
get
involved
is
on
the
website.
Right
on
that.
B
It
is
yep
and
I'll
send
it
to
you
on
slack
right
after
this
too,
so
you
can
put
the
presentation
and
a
couple
links.
You
know
wherever
you
document
your
stuff
cool.
A
Yeah
I
can
see
that
this
would
be
valuable.
I
know
it
seems
when
you're
thinking
about
it
in
advance.
As
far
as
providing
feature
flags
for
an
application.
I
can
see
that
you
know
you
need
to
think
about
it
first,
so
that
you
can
compartmentalize
it
right
and
have
it
have
it
be
able
to
be
dynamic
and
changeable,
but
I
can
see
you
know
just
having
a
standard
way
of
doing.
That
would
be
helpful.
B
Yeah
and
I
think,
there's
some
pretty
interesting
opportunities.
You
know
you
could
even
you
know,
probably
relevant
to
this
group.
If
you
had
something
as
part
of
your
your
you
know
your
pipelines,
you
could
theoretically
have
certain,
maybe
tests
that
only
or
certain
quality
gates-
I
guess
potentially
that
could
test
certain
features
without
it
being
enabled
for
every
other
user.
So
those
could
be
some
interesting
ways
to
basically
get
pretty
early
feedback
about.
B
You
know:
potential
issues
with
new
features
without
impacting
real
users,
especially
because,
like
you
know,
you're,
maybe
a
hardening
or
certainly
a
production
environment
would
is
something
that's
hard
to
to
replicate
locally.
But
if
you're
able
to
kind
of
safely
test
these
features,
I
think
that's
where
feature
flights
could
be
pretty
powerful.
A
A
All
right
well,
as
far
as
anything
else
I
mean
this
was
the
the
star
of
the
show.
Michael
was
a
star
today.
Do
we
have
any
other
topics
we
want
to
discuss?
I
know
we
have
some.
We
still
have
open
pr's
out.
I
think
most
that
are
involved
aren't
on
this
call
today.
So
maybe
we
want
to
save
that
to
the
next
meeting,
but
continue
to
look
over
these
prs
and
at
some
point
we
need
to
merge
those
in.
C
A
I
just
for
curiosity,
if
you're
you
know
just
to
show,
let
me
share
my
screen.
Real,
quick
and
I'll
just
show
what
we
have
going
on
right
now
that
is
active,
so
we
have
some
discussions
about
pipeline
steps
that
is
going
on.
We
have
this.
A
This
pull
request
out,
there's
a
bunch
of
comments
on
here
if
you're
interested
in-
and
you
know
what
we're
talking
about
and
how
we're
thinking
of
proposing
this
standardizing
pipeline
steps
and
how
to
describe
them
and
using
the
right
terminology
that
kind
of
stuff
we've
got
a
lot
of
discussion
happening
here.
A
lot
of
work
has
been
put
into
this
and
then,
in
addition
to
that,
we
had
a
discussion
about
pipeline
stages
and
the
terminology
that
you
know
in
general
organizations
use
for
their
pipelines.
A
A
lot
of
work
also
done
here
on
that
subject,
and
these
have
been
open
for
a
while.
We've
been,
you
know,
pretty
active
in
commenting
on
these
and
making
some
changes
to
these
pull
requests
and
then,
most
recently,
I
think
this
is
when
I
joined
the
group
most
recently.
We
started
talking
about
quality
gates
and
just
an
interesting
discussion
about
what
types
of
quality
gates
are
out
there.
A
We,
we
all,
have
our
different
ideas
of
what's
important
and
how
to
move
our
software
along
the
development
cycle,
but
everyone
has
different
priorities
and
it's
been
interesting
to
collect.
Just
you
know
what
types
of
quality
gates
people
run
when
they
are
run,
and
it's
very
very
much
related
to
pipeline
steps
as
well.
So
we
may
see
some.
B
A
A
Yeah,
all
of
our
notes
are
here.
I
tagged,
you
know
who
el
was
here
today,
I'll
also
send
out.
You
know,
of
course,
the
recording
and
all
of
that,
when
I
send
out
meetings
meeting
minutes
for
this
to
the
group.
Of
course,
if
you're
interested
in
joining
the
group,
if
you
haven't
aren't
on
the
mailing
list,
definitely
get
on
that.