►
From YouTube: 2021-06-08 CNCF TAG Observability Meeting
Description
2021-06-08 CNCF TAG Observability Meeting
A
A
B
B
B
I
will
send
the
zoom
meeting
link
to
or
if
somebody
wants
to
get
get
to
it
before
I
get
there
to
send
the
link
to
the
channel.
B
Exit
yeah,
I'm
not
sure
where
this
old
meeting
link
seems
to
come
from.
I
think
it
might
be,
but
anyway,
so,
let's
get
started.
We
are.
This
is
a
cncf
meeting.
The
code
of
conduct
applies.
We
say
that
at
the
beginning
of
every
meeting,
and
we
will
continue
to
so
please
abide
by
it.
I
put
a
link
to
the
meeting
doc
in
the
chat.
B
Please
sign
in
it
looks
like
we
have
some
things
on
the
agenda
already
on
the
on
on
the
on
the
issue
of
zoom
and
all
of
that,
we're
about
to
move
off
of
the
zoom
platform
onto
the
new
platform
that
the
cncf
has
stood
up.
The
community
sites
we've
just
gotten
the
youtube
stuff
working
yesterday
and
I've
posted
the
last
two
meetings
to
youtube
there.
Now
that
we've
sorted
how
to
access
it
and
whatnot
and
moving
forward,
we
would
expect
to
be
using
the
new
site
versus
zoom.
B
Some
of
these
issues
stop
being
an
issue
with
that.
Do
we
want
to
just
get
into
the
agenda?
I
got
word
that
both
richie
and
bartek
are
both
otherwise
indisposed.
There's
a
number
of
conferences
around
observability
going
on
this
week
and
I
believe
they're
both
they're,
both
speaking
we're
both
helping
with
that.
So.
B
Great
so
I
guess
who
has
the
mh9
the
first
money.
C
It's
still
me
yeah
without
further
ado
handing
over
to
kit
and
and
in
case
you've
missed
it.
There's
a
really
cool
effort
around
standardizing
the
formalization
of
asylums
and
the
two
folks
here
are
the
experts.
They're
gonna
talk
to
us
about
it.
D
Hey
everybody
thanks
for
letting
us
crash
your
party
for
a
little
bit
and
sorry
for
being
late.
We
got
confused
in
the
zoom
link,
but
we
figured
it
out,
so
I'm
gonna.
I
want
to
walk
you
through
ian
and
I
are
together.
We
have
a
few
slides.
We
want
to
share
with
you
we're
going
to
both
present
and
then
ian,
of
course,
has
a
working
demo
that
he's
going
to
show.
So
that
will
be
your
payoff
for
paying
attention
to
our
presentation,
yeah.
So
all
right
cool.
D
D
Air
budget
and
slo
platform
is
a
commercial
product
and
we
use
some
of
the
tech
that
we
built
to
create
the
open
slo
project
along
with
some
other
folks,
we'll
get
into
that
in
just
a
second
and
my
background,
I
was
a
product
manager
on
the
kubernetes
project
in
the
early
days.
So
I
worked
on
a
lot
of
the
ecosystem
and
developer
environment.
There
worked
on
gcr
stuff
like
that
at
google
and
then
worked
been
working
on
developer
tools
for
a
super
long
time
and
then
ian.
E
Yeah,
I'm
ian
bertholm,
you
sorry
lead
at
noble9
here
I've
been
doing
sre
and
devops
at
a
few
different
companies,
most
recently
at
sweet,
green
and
now
at
noble
nine.
I've
been
doing
a
lot
of
work
here
with
the
open,
slow
work.
D
Sweet
all
right,
so
what
is
it?
Okay,
the
the
the
basic
idea
behind
open
slo
is:
there's
a
lot
of
buzz
and
discussion
about
slos
in
the
market
and
there's
a
lot.
That's
come
from
google's
work
and
and
other
you
know,
companies
that
have
adopted
slos
internally,
whether
that's
netflix
or
facebook,
or
you
know,
gitlab
or
lyft
or
uber,
like
all
these
companies
that
have
built
slo,
tooling
internally,
and
one
of
the
interesting
capabilities
that
we're
focused
on
and
I'll,
show
you
how
this
works
is
really
about
declarative.
D
You
know
code
right,
declarative,
yaml
if
you
will,
or
or
some
language,
if
we
want
to
be
legally
animal
side
for
a
second
implementation
detail,
but
the
concept
of
being
able
to
check
it
into
source,
to
be
able
to
unit
test
your
slos
to
be
able
to
make
that
part
of
your
ci
cd,
get
ops,
workflow
and
then
further.
The
reason
why
we
care
about
having
open
standards
is
because
it
allows
you
to
be
vendor
agnostic.
D
It
allows
you
to
as
an
end
user
to
you
know,
to
choose
how
who
you
want
to
have
the
engine
powering
your
slos,
even
if
that
changes
over
time
and
makes
it
easier
for
for
them.
So
for
us
we
want
to
make
sure
that
this
concept
of
slos
is
spread
far
and
wide.
Of
course,
we've.
D
You
know
we
have
a
commercial
motivation
to
have
people
choose
our
back
end,
but
having
the
open,
slo
format
means
choice,
it
means
collaboration
and
when
we
started
asking
people
about
this
and
ian
will
talk
a
little
bit
more
about
the
motivation.
But
we
found
companies
like
gitlab
right
where
they
built
an
internal
slo
language,
and
you
know
they
wanted
to
have
something
that
would
be
easier
to
get
collaboration
to
get
feedback
and
also
for
hiring
purposes
that
you
know.
D
If
this
became
a
standard,
you
know
they'd
be
able
to
find
people
for
that
and
dyna
trace
with
the
captain
project
had
their
own
slo
yaml
format
as
well,
and
so
they've
joined
the
project
and
then
niall
murphy,
who
is
you
know,
notorious
sre?
Who
was
one
of
the
original
authors
worked
at
google
worked
with
microsoft
and
now
he's
struck
out
on
his
own
and
he's
contributing
as
well
so
ian.
You
want
to
talk
a
little
bit
about
the
the
motivation.
E
Yeah
so
like
one
of
the
primary
motivations
that
we
had
is
we
wanted
to
create,
like
that
common
framework
to
express
cslos
in
part,
because
we
have
a
common
language.
We
have
that
lingua
franca
that
we
can
kind
of
all
share
and
understand
so
that
you
know
if
I
go
and
work
on
this
product,
I
have
an
understanding
of
how
to
express
those
slos
or,
if
I
go
over
to
this
company,
I
can
then
work
with
their
slos
there.
E
The
other
part
with
this
is
you
know
as
we're
all
trying
to
approach
this
problem.
Space
of
you
know
how
do
we
define
and
express
these
slos
in
code
and
then
also
express
them
to
users
and
dashboards
and
different
types
of
users?
We
want
to
establish
best
practices.
We
want
to
establish
kind
of
a
framework
of
how
do
we
do
that?
How
do
we
accomplish
this,
and
how
do
we
solve
these
problems,
because
everyone's
kind
of
coming
at
this
from
you
know
different
angles?
E
Different
needs
different
requirements.
You
know
everyone's
looking
at
the
elephant
on
the
different
sides,
so
you
know
how
do
we
come
together
and
have
that
rising
tide?
To
raise
all
the
boats
and
then
like
as
kit,
talked
about
being
able
to
have
a
skill
set,
that's
transferable
so
that,
like
you
know
for
hiring
purposes
or
you
know,
as
a
developer,
being
able
to
go
to
companies
and
say
like
this,
this
is
something
that
I
know
I
can.
I
can
have
an
impact
earlier
in
my
career
there.
E
The
other
part
of
it
is
to
be
able
to
promote
slos
and
drive.
The
adoption
kit
actually
has
had
a
blog
post
about
this
talking
about
breaking
the
build
and
captain
putting
slos
into
the
pipeline
in
order
to
kind
of
force
the
shift
left.
E
I
thought
I
don't
get.
We
want
to
talk
more
about
that.
D
Well,
I
think
I
think
the
key
thing
here
is,
I
think,
of
it,
just
like
like
unit
tests,
if
you
think,
like
pre
the
early
days
of
trying
to
tell
people
like
you,
should
have
unit
tests
like
15
years
ago,
20
years
ago
whatever,
and
you
go
around
and
yell
at
people,
and
I
think,
that's
kind
of
like
the
place.
D
The
state
of
the
art
for
slos
right
now
is
your
teams
will
go
around
team
by
team
and
say
hey,
you
should
have
slos
and
I
think
if
we
can
make
it
part
of
that
dev
workflow
and
make
it
part
of
the
you
know
just
like.
When
the
unit
tests
started
to
break
in
cicd
pipeline
you,
you
would
be
motivated
to
add
unit
tests
to
protect
yourself,
and
I
think
the
slos
code
concept
kind
of
gives
you
that
same
power
and
and
that's
when,
when
marketing
talks
about
shift
left.
E
Yeah
and
that's
one
of
the
things
that
we're
trying
to
do
with
the
oslo
and
we'll
we'll
get
into
that,
but
that
that
tool
set
being
able
to
drive
that
kind
of
slo
is
code
in
ci,
cd
pipelines
and
enforce
that
and
then
also
as
I
talked
about,
we
talked.
We
heard
about
and
kind
of
had
an
anecdotal
awareness
of
other
people
kind
of
doing
this,
and
so
we
wanted
to
kind
of
bring
everyone
together
to
you
know,
bring
all
the
bring
all
of
their
knowledge.
E
Experience
needs
requirements
together
to
help
drive
this
adoption
and
then
being
able
and
then
finally
just
having
less
of
an
interlock
in
you
know
if,
as
a
as
a
company
a
lot
of
the
times,
you
have
that
fear
of
getting
that
vendor
lock
in.
We
wanted
to
be
able
to
have
a
way
of
people,
not
having
that
to
remove
that
one
barrier
for
adoption
and
yeah
and
so
again
further
driving
adoption
slows
industry-wide.
D
And
that
that's
a
good
transition
to
kind
of
the
the
buzz
and
we're
getting
we're
getting
a
bit
of
early
buzz
on
this.
I
think
we
have
maybe
just
crossed
a
hundred
open,
slow
slack
members,
and
you
know
people
on
the.
We
even
got
the
attention
of
the
analysts
right.
We've
got
gartner
and
idc
talking
to
people
about
open,
slo
and
talking
to
end
customers.
There's
a
video
here
that
from
slow
comp
with
idc
talking
to
adobe
stripe
and
then
bull.com
and
skibsk
skibstead,
which
is
a
I
guess,
a
media
company.
D
It
was
so
it's
early
days,
but
you
know
we
already
have
quite
a
few
star,
gazers
and
pr's
coming
in.
I
even
got
brendan
burns
even
filed
an
issue,
so
you
know
we're
we're
on
the
map
and
people
who
joined.
The
interesting
thing
is
like
we
talked
to
people
ahead
of
time
and
we
kind
of
found
people
doing
this
ahead
of
time.
But
since
we
launched
the
project,
we've
had
people
coming
out
of
the
woodwork
saying
you
know
hey.
D
We
were
thinking
about
this
or
I
was
about
to
start
a
project
or
something
like
that
and
they're
kind
of
coming
together.
So
that's
a
really
exciting
thing,
but
without
further
ado
I
think
ian
wants
to
give
a
demo.
I
think
that's
what,
but,
while
he's
just
is.
E
B
Yeah,
this
sounds
great
sorry.
E
Go
for
it
take
it
away
all
right
cool,
so
first
I
want
to
demo
just
the
spec
what
what
that
is
and
then
the
the
tool,
oslo-
and
you
know
just
to
give
you
a
help.
Your
mental
mind
mind
map
of
this.
We
have
the
spec,
which
is
a
written
spec
kind
of
thing
like
graphql,
where
it's,
where
it
is,
it's
a
written,
spec
and
then
there's
different
implementations
that
use
that
spec.
Here
we
have
openslow.com
links
to
our
github
repo.
E
Here,
where
we
have
the
open,
slo
spec
itself,
and
here
we
talked
we
have
we
talked
about
what
what
it
is,
what
type
of
objects
we
have
in
the
yaml,
how
that
can
get
defined
right
now,
you
know
again,
it's
just
a
markdown
file,
but
again
we
go
through
and
define
like
what
the
expected
type
is.
What
the
stanzas
are,
what
the
objects
are,
how
that
works?
You
know
there's
a
lot
here.
E
I
encourage
everyone
to
go
check
it
out
and
again,
there's
been
a
lot
of
like
like
kid
talked
about.
There's
been
a
lot
of
interest
in
here.
So
there's
again,
just
in
like
the
last
like
month.
Maybe
since
we've
announced
this,
if
if
I've
lost
track.
E
E
E
It's
just
they
go
cobra
project,
but
I'm
going
to
run
through
what
it
looks
like
to
validate
those
files
right
over
here
so
right
now
we
have
it
as
a
release,
and
so
you
can
just
pull
down
the
binary
for
whatever
distro
you're,
using
a
platform
just
going
to
run
through
installing
this
right
now.
So
I'm
pulling
down
that
going
to
entire
that
just
to
show
you
guys
from
beginning
to
end
what
that
looks
like
showing
you
all
right.
So
we
have
the
readme
everything,
and
then
we
have
the
oslo
binary.
E
Clear
that
up,
I'm
going
to
pull
down
our
repo
because
it
has
a
number
of
like
test
files,
so
you
can
see
what
a
I
kind
of
expected
the
service,
which
is
one
of
the
objects
that
we
define
and
then
what
an
slo
looks
like
and
validating
those
in
both
like
passing
and
failing
scenarios
go
into
the
directory,
and
so
here's
the
number
of
files
that
we
have
in
there
for
testing
purposes.
E
So
first,
I
want
to
show
you
what
what
a
valid
service
looks
like
a
service
is
kind
of
it's
a
logical
kind
of
grouping
of
slos,
so
it's
very
minimal
basically
right
now,
according
to
spec,
it
just
defines
kind
of
a
name
and
then,
if
we
want
to
validate
that,
we
just
pass
that
file
into
the
possibility.
E
Oh
my
god,
I
don't
think
anyways.
I
passed
that
to
ozil
validate
and
right
now.
This
is
a
valid
one.
So
taking
a
look,
what
an
invalid
service
looks
like
you
can
see
here
we
have
our
api
version,
which
is
foo,
which
is
an
invalid
api
version.
E
So
we
want
to
validate
that
so
we're
going
to
pass
that
to
validate.
We
get
our
an
error
back.
It
also
returns
a
exit
code
appropriate
to
that
too,
so
it
works
in
ci
and
cd.
E
It
won't
just
pass
without
breaking
or
it
will
not
not
pass
without
breaking
slos
are
a
little
bit
more
involved.
There's
a
little
bit
more
to
it.
You
can
see.
We
now
have
objectives,
we
have
a
ratio
metric.
This
is
a
ratio
metric
type
slo.
D
By
the
way
ian,
I
hate
to
interrupt
your
flow
here,
but
your
query:
somebody
pointed
out
to
me
that
I
showed
this
demo
to
and
your
your
good
and
total
queries
are
the
same.
There.
E
D
E
A
good
idea,
yeah,
I
see
see
that
that's
the
magic
at
work
right
there.
So
here
again
passing
and
it's
valid.
E
Oh
yeah,
you
got
to
have
fun
where
you,
where
you
can
here's
a
threshold
based
slo
showing
you
what
that
that
looks
like
where
now
we
have
it
in
the
indicator
block,
we
define
a
threshold
metric
there,
whereas
with
a
ratio,
we
would
define
that
in
our
objectives
block.
E
There
we
go
valid,
so
I
want
to
now
break
this
and
show
you
what
a
breaking
scenario
looks
like
so
here
you
can
see.
We
have
our
budget
method,
which
is
occurrences,
we're
going
to
change
that.
E
There
we
go
show
you
in
fact,
that
that
changed,
so
that
there's
nothing
up
my
sleeve
and
we
get
back
an
error
and
again
an
appropriate
exit
code.
I'm
going
to
change
that.
E
E
And
it's
valid,
so
that's
oslo
in
a
nutshell.
Right
now,
again,
very
nascent
there's
a
lot.
We
want
to
add
to
that.
Well,
a
lot
of
things,
a
lot
of
ideas
we
have
to
have
like
kind
of
beef
up
enforcing
slos
in
a
ci
cd
context.
Is
there
any
questions?
I
know
I
might
have
just
gone
fast
on
that,
but
is
there
any
questions
on
that.
C
Just
an
observation
more
or
less
that
is
it.
This
lends
itself
really
well
to
get
ups
right.
You
could
imagine
having
that
in
there
and
having
a
bot
that
uses
oslo
or
whatever
underlying
library
or
whatever,
to
say
like
hey,
you
know
you
made
a
mistake
here,
or
this
is
invalid
or
whatever,
and
gives
it
back
to
to
the
developer
to
fix
before
they
can
actually
move
on.
E
Yeah,
exactly
that's
the
that's
the
primary
use
case
that
we're
trying
to
envision
on
this.
I
we
want
to
beef
up
that
validation
and
not
just
do
static
analysis
on
it,
but
be
able
to
do
kind
of
more
dynamic
analysis
too,
which
is
kind
of
like
that.
Maybe
the
next
step
from
what
kit
was
just
talking
about,
being
able
to
then
put
in
more
guardrails
for
people
being
like
you.
C
E
This
type
of
query
would
produce
this
type
of
outcome.
You
don't
necessarily
want
that
or
something
like
that,
based
again
on
the
needs
that
people
are
talking
about
and
the
experiences
that
people
are
bringing
to
the
table.
D
Another
and
another
thing
I
think,
which
you
and
I
have
talked
about,
is
also
doing
things
like
presence
checks
and
doing
warnings
instead
of
errors.
It
could
be
useful
too.
So
if
you
imagine
you're
trying
to
drive
slow
adoption
in
your
team
and
you
don't
necessarily
want
to
just
go
start
randomly
breaking
everybody's
build.
D
You
know
this
is
sort
of
like
where,
like
going
back
to
my
unit
test
analogy,
it's
kind
of
like
test
driven
development
right,
it's
like
hey,
let's
just
make
everything
fail
and
then
you
know
the
goal
is
to
like
clean
up
all
the
tests
that
they
pass,
which
is
not
necessarily
you
know.
We
can
debate
the
merit
to
that.
But
to
me
it's
not
the
most
friendly
way
to
do
it.
I
think
the
the
idea
here
you'd
be
able
to
say.
D
Okay,
we
want
to
start
encouraging
people
to
notice
that
they
have
build
warnings
that
are
hey.
You
don't
have
an
slo
to
find
and
then
the
build
warning
sends
you
to
a
helpful.
You
know
article
about
how
to
generate
your
first
slo
or
a
template
you
can
use,
and
then
you
check
that
in
and
then
the
warnings
eventually
can
become
more
more
rigid
over
time
and
and
do
enforcement.
So
you
don't
kind
of
move
backwards,
but
those
are
all
kinds
of
I
mean
and
I'd
love
to
hear
more
use
cases.
D
For
this,
too,
I
mean
there's
been
some
interesting
discussion
about
like
how
should
slis
be
defined.
Can
we
make
it
so
that
there's
a
you
know
an
sli
specification?
Can
we
do
things
like
you
know,
not
necessarily
have
it
in
yaml
or
have
different
file
formats,
because
different
people
have
different
allergic
reactions
to
different
structures
of
data.
D
There's
a
lot
of
room,
I
think
for
for
collaboration
here
and
a
lot
of
room
to
kind
of
experiment.
I
do
have
one
more
slide.
I
wanted
to
share.
I
forgot
to
kind
of
present
before
we
wrapped
up,
though,
specifically
around
governance,
because
a
cncf
presentation
would
not
could
be
complete
without
some
sort
of
discussion
of
governance
and
contribution.
D
So
I
wanted
to
make
sure
we
covered
that
and
then
you
know,
if
there's
more
questions
we
can
take
them,
but
basically
we
want
to
invite
people
to
contribute
right,
and
but
we
want
to
we're
we're
just
in
the
very
early
stages.
We
threw
this
project
out
there
because
we
thought
it
was
something
people
needed
and
we
had
talked
to
these
other
folks.
And
so
there's
like
this
small
core
contributor
group.
D
You
know
five-ish
people,
you
know
it's
noble
mine,
get
lab,
dynatrace
and
nile
are
really
what
we
consider
kind
of
the
core
group
they're,
the
ones
that
you
know,
chop
the
wood
and
carry
the
water
to
get
started,
and
we
haven't
decided
exactly
where
to
take
it.
But
if
this
project
gets
traction-
and
I
mean
real
traction
like
you
know
getting
stars
on
git
hub-
is
you
know
it's
cute
and
whatever?
But
it's
not
real
traction
right
when
people
start
actually
saying
yep,
I'm
gonna
use
this
and
adopted.
D
I
actually
was
talking
to
an
esri
yesterday
who
is
working
on
making
slos
work
for
some
synthetics
and
he's
thinking
about
taking
his
little
app
and
contributing
it.
There's
there's
a
bunch
of
stuff
sort
of
happening
where
this
could
turn
in
something
real
and
then
we'll
consider
our
options.
I
think
you
know
we.
We
love
the
cncf,
I
used
to
be
a
board
member
and
the
see
our
governing
board.
Member
of
the
cncf.
I
helped
launch
the
cncf
in
the
early
days.
We
also
think
apache
could
be
a
good
place
for
us.
D
Cd
cdf
could
be
a
good
place
for
us.
There's
lots
of
different
kind
of
places
for
it
to
go.
We
don't
want
to
jump
the
gun
because
we
know
that
also,
while
it
adds
some
some
good
credibility.
It
also
adds
some
overhead
and
we
want
to
just
make
sure
we
we
think
through
that
and
we're
very
open
to
feedback
there
too,
and
so
we're
trying
to
be.
D
You
know
as
transparent
as
we
can,
but
as
some
people
said,
you
know
it's
not
good
enough
to
just
say
we're
trying
to
be
transparent
and
open
and
whatever
you
have
to
actually
demonstrate
it,
and
so
we'll
take
those
steps
in
an
appropriate
way.
I
don't
know
if
anybody
has
any
questions
or
comments
on
kind
of
how
we're
thinking
about
governance
or
if
you
have
any
advice
for
us.
You
know.
I
definitely
appreciate.
A
B
Yeah,
I
I
would
this.
This
looks
really
cool.
My
brain
is
spinning
in
a
couple
different
directions:
one
early
piece
of
feedback
I
had,
as
I
love
the
approach
of
using
kubernetes
native
objects,
I've
been
reading
up
on
cross,
plane
and
investigating
that,
and
there
are
some
of
the
techniques
that
are
enabled
by
doing
this,
such
as
you
know,
if
you
had
a
terraform
shop,
they
could
use
the
terraform
provider.
You
know
and
then,
because
this
is
a
native
kubernetes
object,
it's
just
automatically
working
there's.
B
Also
some,
I
don't
wanna
say
api
machinery,
because
that's
a
moniker
but
but
there's
some
there's
some
collateral
in
the
in
that
project
as
well,
around
validating,
validating,
hooks
and
and
other
composability
features
like
compositions
and
other
things
where
you
could
easily
see
folks
assembling
a
platform
that
is
inclusive
of
slo
definitions,
and
all
of
that
one
other
question
I
had
to
follow
on
is:
has
any
thought
or
work
been
done
around
automatically
generating
solos?
B
There
are
some
other
projects
that
were
linked
in
pack,
observability
that
I
have
on
my
shortlist
for
friday
to
play
with
to
automatically
generate
slos
from
existing
data
right.
So
I'm
kind
of
curious
like
if,
if,
if
any
work
stream
is
there
to
use
the
ux
of
generating
these
initially
so
that
it's
not
you
know,
death
by
yaml
or
if
there's
some
other
visualization
or
way
to
kind
of
see
this
a
report.
D
Cert
or
something
yeah,
yeah,
good,
all
all
great
questions,
so
one
one
of
the
places
where
that
the
capabilities
you're
talking
about
is
what
bleeds
over
to
kind
of
the
commercial
product
side
of
what
noble9
does?
Okay,
so
we,
you
know-
and
I
don't
want
to
pollute
the
open
source
discussion
with
it,
but
basically
like
what
we
consider
kind
of
proprietary
capabilities.
Are
things
like
the
fact
that
we
can
ingest
data
from
multiple
data
sources?
You
already
have
right.
D
D
Yeah,
so
so,
in
the
context
of
the
open
source,
the
as
this
kind
of
saying,
is
the
stuff
that
we
consider
kind
of
the
proprietary.
I
just
kind
of
give
you
a
sense
of
that,
but
the
the
slo
generation,
the
visualization,
the
data
ingest,
we're
kind
of
treating
that
as
proprietary
pieces
of
attack
right
now
over
time.
But
we'll
see
what
happens,
there
may
be
some
innovation
there,
some
some
some
gradient
on-ramp.
D
So
there's
no
plan
as
of
right
now
to
do
those
things
I
can
see
people
coming
in
and
contributing
differences
or
another
way
to
think
about
this
is
you
could
use
a
proprietary
tool
that
you
know
observability
or
double
line
or
whatever,
to
generate
the
slow
yaml,
which
is
what
we
do
in
our
products?
We
generate
the
the
slo
definition
and
then,
if
that's
open,
slow
compatible.
That
might
be
one
way
and
then
it
will
give
you
a
bridge
from
one
to
the
other.
But
I
don't.
B
Know
that's
fair
and
I'm
sorry
if
I
opened
up
a
can
of
worms,
sorry,
but
but
yeah,
so
just
keeping
the
data
definitions
makes
a
lot
of
sense.
The.
F
A
F
A
B
Say
in
response
to
your
question
around
ecosystem
and
whatnot
is
this:
the
toc
has
recently
provided
some
updates
to
the
sandbox
process.
Okay,
and
just
to
reiterate
that
one
of
the
expectations
in
sandbox
is
you
have
a
lot
of
projects
that
might
merge
or
or
collaborate
or
they
might
be,
solving
the
same
problems
in
different
directions,
and
so
I
would
just
yeah
just
as
a
blanket
statement.
B
I
encourage
you
to
check
out
the
new
the
new
sandbox
process,
yeah,
it's
a
bit
more
streamlined,
yeah
and
yeah,
but
I'm
sure
you're,
aware.
D
Well,
yeah
and
we
haven't
totally
rocked
the
updates
yet,
but
that
is
a
good,
a
good
reminder
to
go.
Look
at.
I
think
I
think
the
main
from
talking
to
the
people
who
are
continuing
the
project.
I
think
the
main
thing
right
now
is
trying
to
just
get
the
bootstrap
of
like
these
sort
of
very
basic
capabilities
and
process.
D
Some
of
these
pull
requests,
and
things
like
that
and
and
then
I
think,
is
it
step
two
once
that
gets
to
a
kind
of
a
certain
level
of
of
you
know
feeling
good
about
the
attack.
Then
I
think
we'll
start
exploring
the
the
governance
piece
a
little
bit
more.
So
that's
awesome
awesome.
Thank
you
for
sharing.
B
Lastly,
if
folks
want
to
play
immediately,
I
know
you
had
some
links
earlier.
Will
you
be
sharing
these
slides.
D
Yeah,
I
will
go
ahead
and
make
these
slides
public.
You
know
publicly
viewable
and
I
will
link
them
in
the
in
the
tag.
I
actually
went
back
while
we
were
doing
this
and
I
added
a
video
here
as
well,
which
has
the
demo
video
which
is
linked
on
the
open,
slow
homepage.
But
just
so
you
can.
You
can
watch
that
again
but
ian
correct
me
if
I'm
wrong,
but
you
can
basically
go
and
download
an
oslo
and
just
go
and
there's
some
sam
there's
a
sample.
D
You
go
in
here,
there's
actually
the
sample.
Where
are
they.
E
D
In
test
yeah,
so
here
there's
actually
passing
and
failing
example,
doc,
slowly,
ammos
and
then
so,
if
you
go
in
here
like
you
can
see
the
ones
that
he
was
using
in
the
demo
so
everything's
there
and
then
this
definition
is
back
in
the
open,
slow,
open,
slow.
C
D
B
To
codify
the
the
data
model
and
whatnot
does
anyone
else
have
any
other
questions
for
our
guests
today?.
A
I
was
kind
of
wondering
how
you're
seeing
like,
given
that
we're
like
in
cncf
space
like
how,
how
do
you
think
it
can
integrate
with
already
existing
cncf
projects
right
like
prometheus,
open
telemetry,
I
don't
know
fluentd
or
whatever
you
have
kind
of
like
already
existing.
Are
there
any
plans
or
is
it
like
kind
of
kind
of
orthogonal
and
evolving
throughout
the
time
going
forward.
D
I
would
say
that
there's
not
necessarily
concrete
plans.
I
would
say
at
this
point
I
think,
there's
been
some
discussion.
I
mean
definitely
in
the
prometheus
thanos
side.
I
think,
there's
a
very
logical
connection
there.
I
know
there's
already
been
some
work
done
to
do
eslos
and
prometheus
and
some
different
projects.
I
can't
remember
the
name
of
the
video.
What
I'm
talking
about,
there's
like
that
that
tool
that
generates
slos
and,
I
think,
there's
a
very
logical
connection
between
slos
and
envoy
or
other
service
meshes.
D
I
think
this
is
really
you
kind
of
think
about
like
so
you
have
this
sort
of
telemetry
where
you're
collecting
metrics
and
some
of
that
can
be
generated
by
kind
of
the
service
mesh.
Then
you
would
have
slows
you'd
want
to
tune.
I
think
there's
an
opportunity
for
open
source
projects
to
publish
their
slos
right.
D
If
you
think
of
like
I
have
a
service
and
there's
a
set
of
slis
and
there's
a
set
of
slos
that
will
go
with
it
and
having
a
common
end
point
you
could
say:
okay,
I
have
the
service
and
I
reference
that
that
endpoint
on
that
service
and
I
can
ingest
an
sli
stream
and
then
I
can
apply
my
own
slo
on
top
of
it
and
define
what's
important
for
my
usage
of
that
service
right.
I
think
those
are
some.
D
You
know
some
interesting
possible
possibilities,
but
definitely
we'll
need
help
in
kind
of
socializing
that
and
seeing
if
it
can
make
sense.
In
those
cases,
I
actually
think
there's
there's
also
slo-based,
auto
scaling.
That
could
be
a
really
amazing
use
case.
So
you
think
about
like
what
some
of
the
slo
use
cases
right.
D
We've
talked
a
bit
about
the
get
op
side,
because
that's
what
we
have
in
oslo,
but
the
use
case
is
around
progressive
release
and
enroll
back
so
think,
like
feature
flagging
canary
releases,
blue
greens,
rolling
updates
all
of
that
stuff
driven
by
slo,
so
that
you
can
see
if
the
the
updated
changes
actually
have
an
impact.
A
slow-based,
auto
scaling,
which
is
a
more
elegant
kind
of
way
of
doing,
auto
scaling
than
than
cpu
based
or
resource
based,
which
is
cpu
based,
is
great
in
some
context.
D
But
if
you're
trying
to
manage
it
to
user
expectation,
you
can
model
the
slo.
So
I
saw
a
demo
yesterday
from
this
developer.
I
know
you
guys
know
bhargav
from
tailwinds,
but
he
built
a
basically
an
auto
scale
of
node
and
pod,
auto
scaler.
That
can
accept
slo-based
signals
and
then
use
that
to
either
scale
up
the
pods
from
a
replication,
controller
or
scale
up
the
nodes
and
can
also
do
like
load
eviction.
And
the
idea
is
that
you
can
tune.
Then
the
error,
budgets
right
and
then
it's
it's
so.
D
Auto
scaling
capabilities
could
be
useful
in
the
cloud
as
well,
but
anyway,
those
are
so
like.
Those
are
some
of
the
use
cases
I
think
are
super
interesting
for
sure.
This
is
not
something
this.
This
project
cannot
live
alone,
like
it's
kind
of
useless
right.
It's
cute,
like
hey,
I
have
a
yaml
file,
that's
validated,
but
if
it
really
have
value
it's
getting
that
the
semantic
definition
of
slos
to
work
with
these
other
data
sources
and
and
compute
platforms,
things
like
that
yeah.
D
A
A
Yeah
exactly
yeah,
I
mean
I,
I
was
like
working
on
the
slo
for
kubernetes
and
prometheus,
like
in
intersecting
those,
so
I
think
yeah
there's
a
lot
of
opportunity,
kind
of
like
in
the
open
source
ecosystem
there
to
make
it
work.
I
would.
B
No,
our
meeting
exists
to
have
stuff
like
this,
be
the
topic
of
discussion
you're
not
putting
this
out
at
all.
This
is
up
the
center
line.
You
know
the
tag.
The
technical
advisor
group
exists
for
a
whole
bunch
of
reasons,
but
the
charter
is
quite
broad
and
a
major
part
of
that
charter
is
identifying
gaps
in
the
ecosystem,
identifying
new
projects
that
may
opt
to
join
the
cncf
umbrella.
B
B
We've
got
some
some
stuff
coming
up
all
right,
yeah,
let's,
let's
walk
through
the
rest
of
this
really
quickly.
So
next
is
is
around
collaboration
and
and
starting
since
we
had
identified
a
workstream
to
facilitate
in-person
meetups
once
the
pandemic
passes
as
it
will,
we
have
to
trust
and
people
start
meeting
up
again.
So
I
think
this
is
a
follow-on
discussion.
Is
here
he's
not
here
today,
so
I
guess
we
could
skip
it
all
right.
I'm
here.
G
I
just
wanted
to
discuss
a
pro
proper
framework
for
events
and
meetups,
and
you
know
you
had
a
bunch
of
suggestions
regarding
interviews
and
all
of
that
right.
So
I
just
figured
if
we
have
a
proper
framework
or
something
like
that
that
we
can
use
to
create
events
and
all
of
that
part
right
on
multiple
platforms.
I'm
pretty
sure,
there's
gonna
be
a
twitter
handle
going
ahead.
There's
there
will
probably
be
a
linkedin
group
or
something
right
for
tag
observability
as
such.
G
So
I
just
wanted
to
check
in
get
everyone's
views
on
how
we
can
have
a
proper
framework
right
either
we
can
have
it
on
a
single
document
or
we
can
have
a
data
ratio
template
whatever
works
for
everyone,
and
secondly,
I
mean
with
com
with
the
community
engagement
part
and
everything
right.
It
might
also
be
a
good
idea
for
us
to
nominate
some
people
like
two
three
people
to
a
sort
of
communications
team
or
a
communication
sub
team
within
the
working
group
like
the
way
working
group
githubs
has
done
this
right.
G
They
have
a
two
three
person
volunteer
team.
Obviously
everyone
is
welcome
to
pitch
in.
Everyone
is
welcome
to
collaborate,
but
they
are
probably
the
ones
to
you
know
get
in
touch
with,
while
organizing
a
meetup
or
something
like
that,
so
just
wanted
to
get
everyone's
views
on
that.
B
Yeah,
so
I
linked
in
a
github
issue
that
has
been
there
for
a
little
while
we're
we're
just
now
putting
in
place
some
of
the
stuff
so
that
we
can
manage
things
in
in
parallel
I'll
get
to
it
at
the
end
here.
But
but
yeah
put
put
your
thoughts
on
that
issue,
I
think
the
the
way
that
we
conceive
tags
running
and
what
the
way
other
others
do
is
they
generate
working
groups
that
are
time
bounded
have
artifacts
as
an
output.
B
Typically
a
recommendation-
or
you
know
some
some
conclusion.
You
know
and
they're
scoped
as
such,
so
I
would
propose
that
we
make
a
working
group.
I
said,
to
cover
these
issues
and
come
up
with
a
solution
accelerator
if
you
will
of
sorts.
You
know
that
used
to
launch
us
regarding
some
of
your
comments
around
zoom
and
and
timing
outs
and
zoom
limits,
I
believe,
as
we
engage
with
the
new
cncf
platform
for
for
meetings
as
well
as
events.
Some
of
that
should
be
mitigated
or
ameliorated.
G
Yeah,
I
think
it's
gonna
be
baby,
but
matt.
Please
correct
me
if
I'm
wrong,
but
from
what
I
understand
see
if
cscf
is
also
providing
all
the
tags
with
their
own
youtube
playlists
and
all
of
that
right.
B
I'll
be
covering
some
of
that
at
the
very
at
the
very
tail
end.
But
yes,
we
have
a
youtube
space
there.
Once
we
have
a
logo,
we
need
a
logo
before
we
can
have
this
weirdly,
but
there's
actually
a
cncf
landing
zone
for
for
a
tag
we'll
get
stickers,
which
is
what
I'm
very
excited
for,
because
I'm
that
way,
but
a
bunch
of
other
stuff
like
that,
should
become
accessible
to
us.
So.
G
So
I
think,
let's
just
come
back
to
that
later,
once
you
once
we
are
done
with
all
the
other
items
right.
B
Sure,
okay,
great
okay,
let's
see
right
we're
at
40
minutes,
so,
okay
xk6
distributed
tracing.
B
One
I
didn't
mean
to
shut
you
down
early.
I
think
we'll
get
there
for
sure.
F
F
So
I'm
here
to
do
a
small
proof
of
concept
of
xp67
tracy.
First,
I
would
like
to
introduce
like
what's
g6
right,
because
maybe
you're
wondering
that
and
kisses
is
an
open
source
last
testing
tool.
The
cool
thing
is
that
it
lets
you
create
your
tests
as
javascript.
The
tool
by
itself
is
pretty
go
it.
As
I
said,
you
can
write
everything
as
code.
It
supports
multiple
protocols,
http
trpc
also
it
supports
like
creating
metrics
inside
the
tool
and
exporting
them
to
a
wide
array
of
backends
yeah.
F
F
The
plugin
system
is
very
easy
to
like
to
use
and
to
extend
under,
like
some
extensions
already
available
from
cal
centering
extensions
to
docker,
kubernetes
crypto,
multiple
extensions
for
different
things,
yeah
the
community
is,
is
liking.
It
so
yeah,
I'm
pretty
happy
about
that
today,
I'm
here
to
talk
about
one
extension
that
I
developed
with
a
college
as
a
proof
of
concept
for
having
open,
telemetry
instrumentation
on
the
http
path
of
of
of
k6,
and
that
means
that
you
can
use
k6
to
run
your
load
test.
F
Your
integration
test,
your
whatever
test,
you
can
track
like
the
request
right,
the
full
path,
which
is
still
the
tourism.
I'm
going
to
use
this.
As
my
thing
during
the
demo,
it
has
like
two
services
instrumented
with
open
telemetry.
It
has
one
collector
tempo
and
grafana.
Everything
runs
on
docker
compose.
So,
if
you
want
to
play
with
it
locally,
you
can
yeah.
F
F
F
I'm
going
to
run
this
script
with
k61.
I
already
have
g6
installed
so
yeah.
This
gives
an
example
that
there
is,
and
it's
running
at
the
end.
K6
is
going
to
output
like
a
small
summary
with
all
the
metrics
and
stuff,
but
we
want
to
see
it
right
now,
yeah
it
finishes,
and
now
we
want
to
like
to
find
that
phrase
right
from
there
from
the
full
service.
The
thing
with
grafana
tempo
is
that
if
you
want
to
find
the
trace,
you
have
to
know
the
price
id
there
is
like.
F
No
way
to
index
the
traces
or
anything
like
that,
yet
so
what
I'm
doing
is
on
the
on
the
full
service,
I'm
logging
at
each
request,
so
we
can
pick
some
trace
id
and
see
the
first.
So
I
want
to
copy
this.
F
F
Yeah,
you
can
see
the
trace,
nothing,
fancy
just
two
services
doing
some
http
requests
so
yeah.
This
is
how
it
looks
like
with
playing
physics
and
maybe
you're
thinking.
Okay,
that's
nice!
Okay,
you
need
some
traffic
on
my
app
or
yeah,
but
we
wanted
to
to
have
this.
This
ability
to
track
these
requests
from
the
lowest
generator
because,
for
example,
if
you're
doing
synthetic
monitoring
or
cause
engineering
or
loss
testing
or
whatever,
it
can
be
interesting
to
understand
how
a
specific
request
in
some
point
in
time
affected
the
rest
of
the
system.
F
So,
with
this
extension,
you
can
do
that
how
you
can
use
the
extension.
The
the
instructions
are
quite
easy.
You
have
first
to
download
like
xk6
xk6
is
a
smart
helper
to
create
a
k6
binary
with
all
the
extensions
that
you
want.
Once
you
have
ace
pieces,
you
can
just
run
xk6
with
the
extension,
so
we're
going
to
do
just
that.
F
Holding
okay,
that's
ready!
You
can
see
that!
Well
now
we
have
like
a
new
binary
on
your
p6
binary
once
we
have
that
we'll
have
to
modify
this
test
right,
because
we
have
an
extension
with
some
new
functionality
2k6
and
we
have
to
change
some
things,
not
a
lot
but
yeah
some
things.
F
Then
I
can,
if
I
want
interrupt
with
the
trace
id,
will
write
down
the
dress
id
on
the
response
object,
so
you
can
play
with
it
as
you
want.
You
can
lock
it,
for
example,
if
the
request
matches
some
status
or
whatever
you
can
play
with
it,
and
then
we
have
this
at
the
end
as
some
kind
of
like
life
thicker
thing
of
q6,
just
to
shut
down
the
instrumentation
gracefully
so
without
loose
traces
or
anything
like
that.
F
So
as
you
can
see,
I'm
using
the
otlp
a
grpc.
If
I
remember
currently
exporter
and
we
are
using
the
w3c
propagator
and
we
are
going
to
run
this
new
test,
let's
see
what
happens
so,
let's
do
this
example.
F
As
you
can
see,
we
are
logging
the
trace
like
this
yeah.
Now
we
don't
have
to
go
to
the
full
service
to
find
the
traces
we
can
see
them
here.
I
can't
piece
just
one:
one
trace
one:
first
id
I'm
going
to
rafana
paste
it
and,
as
you
can
see,
I'm
going
to
see
the
full
experience
from
the
last
generator.
F
There
are
some
expanse
that
are
for
generated
by
k6
around
the
http
connection.
I
have
a
full
trade
for
like
for
the
full
request,
it's
kind
of
flexible.
We
use
open
telemetry,
so
we
have
support
for
a
wider
right
of
propagators
and
exporters.
F
Maybe
you
don't
need
to
export
the
data
that
physics
is
generating.
Maybe
you
only
care
about
being
able
to
start
the
trace
on
physics,
and
you
can
do
that.
There
is
a
nope
exporter,
and
that
means
that,
if
use
the
nuke
exporter,
q6
won't
export
the
spans
that
were
generated
from
k6,
but
we
get
the
trace
id,
so
we
can
play
with
it.
We
can
still
correlate
each
request
right
with
the
with
what
happens
on
the
back
end
yeah.
F
A
B
Yeah
we're
using
k6
quite
heavily
in
my
day
job
happily,
so
we
have
some
folks
that
are
interested.
That
I'll
be
pointing
your
way
that
are,
you
know,
we're
using
open
telemetry
as
well,
and
we've
rolled
out,
tracing
and
and
merging
our
load
test
and,
with
this
looks
exciting
so
awesome
before
we
move
on.
Does
anyone
else
have
additional
comments
or
questions.
A
A
F
Okay,
I
don't
work
on
the
k6
open
source
thing,
but
I
would
say
that
is
kind
of
lightweight
we're
using
goja,
because
k6
is
written
in
gold
and
we
spawn
like
goja
interpreters
for
javascript
in
memory
and
from
what
I
understand.
It's
kinda
lightweight
a
lot
but
yeah,
probably
I'm
not
the
best
one.
To
answer
that
question
so.
B
F
B
Oh
no,
I
was
there
saying.
Thank
you,
oh
thank
you
very
much
and
welcome
we'll
see
you
in
the
future.
Bye
don't
be
shy,
is
arthur
here,
I'm
guessing
this
next
one
is
for
him.
B
That,
oh
okay,
oh
you
know
what
bartek
did
this
on
the
observable
white
paper?
Is
there
anything
you
want
to
speak
to
or
should
we
take
it
offline?
I
know
there
was
some
discussion
around
the
app
delivery,
or
rather
the
security
white
paper
that
came
out
of
the
app
delivery
team.
B
I
think
I
can't
remember
the
specifics,
but
a
week
ago,
there's
a
white
paper
that
they've
done
on
github
in
another
tag
and-
and
I
had
spoken
to
some
folks
there
and
they
found
keeping
thing
once
they
moved
from
google
doc
to
a
series
of
markdowns.
They
found
it
easier
to
fan
out
and
and
have
review
and
whatnot.
I
don't
know,
though,
if
that's
a
process
you
all
want
to
do.
C
Out
for
a
while
right,
so
I
think
the
most
pressing
issue
is
that
we
we
would
love
to
have
a
you
know
every
other
week
where
we
have
another.
You
know
entire
the
entire
team
meeting
for
this
working
group
for
the
observability
white
people
working
group
to
to
meet
right.
C
So
if
we
could
use
this
15
minutes
or
whatever
every
other
week
like
next
week,
for
example,
to
get
a
progress
there
where,
under
the
chairman,
chairpersonship
of
arthur
and
simone,
we
get
that
done
and
and
have
a
progress
there
and
you
know,
can
really
get
that
out
of
the
door.
That
was
essentially
the
main.
The
main
motivation
behind
that
that
common
part
they've
left
here.
B
Cool,
I
think
that
will
also
be
covered
in
my
last
little
blurb,
because
there's
some
there's
some
machinery
for
working
groups
that
are
also
that
we
get
for
free.
So
I
would
say
at
a
high
level,
working
groups
you
know
once
formed
are
free
to
meet,
however,
wherever
they
like,
we
can
make
playlists
in
our
new
youtube
channel
for
working
groups.
B
So,
just
like,
we
have
meetings
that
have
support,
for
you
know,
archiving
them
to
youtube
and
whatnot
working
groups
can
use
that
as
well
and
and
it's
the
expectation
that
we
build
out
playlists
earlier
someone
had
talked
about
a
communication
thing.
I
think,
what
a
communication
body
within
a
working
group-
that's
certainly
fine,
I
think,
for
tag
observability.
B
I
should
have
things
documented
for
the
next.
For
the
next
meeting.
We
have
around
some
specific
proposals
around
that,
but
yeah
we
have
this
new
facility
with
youtube
between
twitter,
social.
You
know
social
media
of
all
kinds
of
linkedin
and
twitter
and
the
rest.
You
know
we
could
really
use
contributions
from
folks
that
have
experience
running
media
outreach
or
social
media
stuff,
or
you
know
just
defining
a
program
that
there's
all
sorts
of
things
we
could
do.
You
know
we.
B
You
know
we
had
discussed
previously
things
like
interviewing.
You
know
some
of
the
folks
that
came
before
us
right.
Software,
engineering
and
cloud
native
is
also
new,
but
we're
now
a
multi-generational
discipline
and
we
weren't
before
we
have
multiple
generations
of
engineers
working
right.
So
there's
industry-wise
there's
a
knowledge
transfer
that
needs
to
happen.
B
So
you
know,
perhaps
the
tag
could
do
things
like
interview,
the
folks
that
made
telegraph
and
stats
to
you
and
collect
d
and
then
some
of
the
things
that
came
before
the
tools
we
have
now
to
interview
them
and
ask
them
questions
like
you
know,
back
in
the
90s
or
2000s
when
the
stuff
was
designed
or
earlier.
You
know
what
couldn't
you
do
because
there
wasn't
enough
compute
or
memory
or
whatever
what
you
know.
B
What
insights
might
you
have
now
that
we
do
have
these
capabilities,
so
we
could
do
like
interesting
interview
series
like
that
we
could
do
deep.
Dives
we
could
do
lightning
talks.
You
know
we
can
really.
We
were
instructed
by
amy
and
the
toc
to
really
be
creative,
with
our
youtube
presence.
So
there's
a
huge
opportunity
for
us
to
do
effectively,
whatever
we
think
makes
sense
and
would
be
awesome
so
well
as
it
regards
the
working
groups.
B
I
think
meeting
on
the
off
meeting
off
weeks
is
great
if
that
time
works,
but
again
that's
up
to
the
folks
working
on
it.
You
know,
but
when
you
do
decide
we
can
have
those
working
group
meetings
be
in
the
cncf
events
page.
They
can
be
in
our
space.
They
can
be
in
our
youtube
stuff.
You
know
all
of
the
meeting
support.
That's
all
there
for
working
groups
to
self-organize
and,
however,
however,
they
see
fit.
D
Hey
matt,
I'm
sorry
to
interject,
but
just
on
the
topic
of
youtube,
I
we
run
a
slightly
successful
youtube
channel
and
some
of
the
stuff
that's
worked
really
well.
I
just
wanted
to
share
shorter
videos
are
always
better,
like
always
better
and
one
of
the
things
we've
done
when
we
did
the
slow,
conf
videos.
We
did.
This
thing
called
the
buddy
system,
where
we
assigned
two
people
to
each
work
on
each
talk,
and
it
may
be
one
of
the
single
greatest
innovations
of
my
entire
career.
D
To
be
honest
because
normally
chasing
down,
videos
and
doing
it
ahead
of
time
is
like
one
of
the
worst
things
you
could
possibly
imagine.
We
had
70
percent
of
our
videos
submitted
on
time
and
requiring
zero
editing
for
slo
conf,
which
is
just
an
insane
thing
and
it
all
I
credit,
basically
the
buddy
system
for
the
whole
thing,
because
it
created
social
accountability,
it
created
ownership,
it
gave
people
an
audience,
it
gave
them
a
person
to
impress
and
sage
feedback
on
their
talks
and
they
got
that
in
exchange.
D
So
it
just
really
changed
the
game.
So
I
was
just
something
to
think
about
and
giving
people
constraints
really
helps
them
get
creative.
So
if
you
say
okay,
we're
going
to
say
it's
only,
you
know
it
has
to
be
about
this
topic.
It
has
to
be
this
this
length
of
time
it
has
to
have
a
clear
takeaway
or
whatever
it
is
that
you
create,
as
rules
will
drive
that
that
creativity
and
then
the
other
thing
we've
done.
A
lot
is
interviews
that
have
show
and
tells
we
didn't
do
it
for
slow
conf.
D
But
when
I
interview
people
I
asked
them
to
do
hey.
Do
you
have
something
you
can
show
and
tell
with
me?
I
did
one
as
an
example
with
matt
moore
from
the
k-native
projects,
where
he
basically
just
showed
me
a
bug,
and
it
was
like.
Maybe
like
one
of
the
most
interesting
conversations
I
ever
had
with
somebody
about
about
a
bug
and
we
published
it
to
youtube
and
you
know,
got
a
bunch
of
hits
and
there's
there's
some
other
examples
like
that
too.
That's
great
yeah,
I
I.
B
I
gave
you
a
call
out
in
the
doc
if
you
want
to
provide
some
details
so
that
we
can
follow
up
on
it.
We
should
absolutely
talk
some
more.
It
sounds
like
you
might
have
some
ideas
for
launching
our
youtube
presence,
or
at
least
contributing
to
it
right,
so
that,
thank
you.
Thank
you.
In
the
interest
of
time
we
have
like
three
minutes
left
here
so
but
that's
great.
B
Let's
follow
up
on
it
and
and
if
you're
around
on
next
meeting,
we
could
we
could
talk
at
more
lanes
on
the
topic.
I've
I've
taken
so
there's
a
new
github
project.
I
put
up
it's
just
a
simple
kanban
board
sort
of.
I
would
expect
that
if
we
are
planning
for
our
success,
we're
gonna
have
a
lot
of
contributors
right
and
there's
a
lot
of
things
to
happen
in
parallel.
B
So
this
meeting
that
we're
in
now
I
would
expect,
would
seem
more
like
the
toc
meetings,
where
working
groups
are
reporting
out
on
status,
we
could
do
like
a
quick,
stand-up
style.
You
know
15-20
minutes
on
any
blocking
issues
and
just
report
outs
and
then
leave
the
the
the
latter
portion
for
an
interesting
guest,
a
topic,
something
that
requires
more.
But
but,
as
we
scale
up,
we're
going
to
need
to,
you
know
just
manage
it
accordingly,
with
work
happening
asynchronously
and
in
parallel.
B
So
this
is
not
an
exhaustive
list,
but
I've
I've
seeded
that
new
board
with
some
ideas
that
we've
talked
about
over
the
last
few
weeks.
I
would
encourage
anyone
if
you're
interested
in
these
things
add
yourself
to
the
issue.
I
think
I
would
rather
than
instead
of
saying
like
this
is
our
process.
B
I
wanted
to
throw
it
out
there
and
say
what
do
you
all
think
of
a
lightweight
kanban
so
that
we
could
manage
the
life
cycle
of
these
of
these
working
groups
and
they
can
have
clear
defined
ownership
and
there's
lots
of
best
practices
that
we
can.
We
can
use
that
other
tags
are
using
as
well
and
there's
some
chatter
on
that
as
well.
But
what
do
folks
think
about
the
general
approach?
B
And,
lastly,
I
wanted
to
augment
a
third
project
with
an
I.
I
can't
come
up
with
a
better
name,
but
I
have
one
at
work.
We
call
the
idea
pipeline
and
it's
sort
of
like
no
idea
too
big,
too
small.
It's
just
a
way
to
get
started,
oftentimes
the
barrier
to
starting
on
a
project
or
starting
on
an
idea
is
just
literally
starting,
so
you
know
having
a
low
friction
way
to
just
get
ideas
out
there
like.
I
would
like
to
be
able
to
visualize
network
traffic
with
liquor
do
using
a
hololens
too.
B
A
G
Think
matt
quick
follow-up
around
the
working
group
idea.
Do
we
have
a
specific
template
to
propose
a
working
group
or
something
like
that.
B
I'm
so
happy
you
asked
there
is
actually
an
issue
for
that.
It's
the
first
one
there
that
issue
number
nine
to
have
exactly
a
template.
That
has
those
things
so
that
when
you
make
a
new
issue
on
a
particular
board,
it
pops
up
a
really
low
friction
way
to
do
that.
The
key
things
about
a
working
group
are:
they
should
have
ideally
more
than
one
chair
or
a
leader.
They
have
a
a
time
bounded
period,
and
then
they
have
outputs
that
are
there.
B
B
A
B
I
I
took
the
issue
that
we
were
using
to
track
the
white
paper
and
I
just
put
it
into
in
progress
because
any
kind
of
process
at
all.
So
again,
I'm
hoping
that
over
the
next
few
weeks,
in
some
of
the
issues
that
I've
linked
here
most
notably
issue
number
nine,
we
could
kind
of
come
up
with
what
that
is
formally
we're
about
out
of
time.
B
Now
I
did
want
to
leave
you
all
with
one
parting
thought,
at
least
that
I've
been
thinking
about
over
the
last
few
weeks
and
that's
how
can
humans
best
perceive
reconciliatory
feedback
loops
from
system
stereo
control
theory.
You
know,
feedback
groups
are
at
the
heart
of
git
ops
at
the
heart
of
kubernetes.
The
controller
pattern
operator
patterns
all
of
this
stuff,
and
so,
as
these
systems
become
increasingly
complex,
we're
going
to
need
ways
to
to
think
about.
B
You
know
how
do
these
things
aggregate?
How
do
they
compare
with
each
other?
How
do
we
reason
on
them?
How
do
we
visualize
them?
You
know
we're
doing
it
now
with
metrics
and
things
like
that
and
that's
fine,
but
I
have
to
believe
in
the
universe
of
human
computer
interaction
research
over
the
last
40
years.
There
has
the
way
humans
rock
these.
These
reconciler
patterns
that
are
stacked
up
and
and
nested,
if
you
will
and
and
have
interplays,
is
gonna,
be
increasingly
relevant.
B
So
I've
reached
out
to
some
folks
at
the
get
ops
working
group
about
this,
but
it's
just
a
general
thing
in
the
back
of
my
head
for
the
last
couple
of
weeks.
So
if
anyone
has
ideas,
I'll
see
you
online
or
in
the
next
meeting,
but
is
there
anything
else
that
folks
want
to
mention
before
we're?
G
We're
we're
technically
at
plus
30
seconds,
so
apologies.
I
just
wanted
to
ask
one
more
thing,
so
I
was
reading
up
on
the
observability
white
paper
and
do
you
guys
think
it
make?
It
makes
any
sense
for
us
to
have
a
like
sort
of
a
skeletal
document,
basically
on
the
concept
of
explain
it
to
me,
like
I'm
five-year-old
kind
of
thing,
do
you
think
it
makes
any
sense
to
do
that.
G
I
so
basically
like
a
skeletal
document
of
the
observability
white
paper,
so
I
mean
it
contains
the
brief
introduction,
or
I
mean
things
in
a
simpler
language
or
things
like
that
to
help
people
understand
it
better.
A
G
What
I
mean
by
that
is
like
white
papers
are
generally
supposed
to.
You
know
include
a
lot
of
concepts
and
they're
supposed
to
include
definitions
and
everything
around
that
right,
like
they
they're
supposed
to
include
a
lot
of
data
and
everything
around
all
concepts.
What
I'm
trying
to
say
is,
would
it
I'm
sorry.
C
B
And
thank
you
for
the
feedback
yeah
in
the
interest
of
time.
I
think
we
need
to
close
the
meeting
here,
we're
at
plus
three.
So
thank
you.
Everyone
who
stayed
to
the
bitter
end-
and
I
will
see
you
next
time
and
I
think
next
time,
if
I'll
just
throw
out
there,
there's
a
lot
of
new
faces
in
two
weeks.
I'd
love
to
open
the
meeting
with.
A
We
haven't
done
in
a
while
around
of
intros
just
so
that
we
can
all
know
each
other
and
who
we
are.
But.