►
From YouTube: SIG Instrumentation 20210204
Description
SIG Instrumentation Meeting: Feb 4th 2020
B
B
A
Okay-
let's
open
this
guy
up,
so
this
is
what
I
am
tracking
currently
for
the
sig
for
caps.
We
want
to
do
in
this
release,
so
let
me
just
make
sure
that
everybody
has
the
link
I'll
put
it
in
the
chat.
If
I
can
figure
out
how
to
do
that,
there
we
go
so
this
is
kind
of
where
we're
at
the
cap
process
has
changed
a
little
bit
in
121,
so
I
just
wanted
to
go
over.
A
It
make
sure
everyone
knows
what's
going
on
and
like
figure
out
which
caps
are
going
into
the
next
release.
So
what's
going
on
here,
caps
are
anything
that
are
like
net
new
to
cube
or
like
changes
that
need
to
be
discussed
with
other
cigs
or
things
like
that.
So
they're
not
like
bug
fixes
they're
not
like
website
typo
updates,
it's
specifically
for
features
and
for
features.
We
need
some
way
to
track
them
project
wide.
A
So
this
is
how
we
do
it
and
we
have
a
new
process
in
121
where,
basically,
previously,
the
release
team
just
goes
and
tracks.
Everything
for
us-
and
all
we
have
to
kind
of
do-
is
like
once
things
get
the
milestone
put
on
them.
We
kind
of
watch
them
for
the
duration
of
the
release,
so
this
is
kind
of
the.
This
is
the
list
based
on
this
kept
issue
list
of
everything
that
we
currently
have
on
our
backlog,
and
so
I've
been
going
through
this
basically
saying.
A
Okay,
we've
got
nine
of
these.
What
are
we
doing
for
each
of
them?
So
the
first
one
on
the
list
was
metric,
cardinality
enforcement.
I
talked
to
the
owners
of
this
one
and
the
answer
is
we're
not
doing
anything
in
121
we're
letting
it
lay
in
alpha
and
the
our
next
steps
are
to
determine
when
this
moves
to
beta.
So
I
can't
see
han,
but
I'm
assuming
that
han
is
giving
a
thumbs
up
he's
nodding
his
head.
C
A
Yeah,
so
no
no
work
to
be
done
on
this
one,
so
we're
not
doing
anything
on
121.
So
it's
not
going
to
get
tracked
this
one
defend
against
logging
secrets
against
via
static
analysis.
So
I
think
both
of
these
two
are
moving
to
security.
This
one
is
targeting
beta
in
121.
I
think
the
prs
may
already
even
be
up
for
it
and
there's
a
pr.
I
guess
there's
a
pr
for
this
moving
to
security
and
then
it
becomes
their
problem,
so
we
have
to
like
give
it
a
thumbs
up.
A
C
A
A
C
A
A
A
Is
purely
applied
on
the
call,
I
don't
think
so.
I
already
spoke
with
him,
so
this
one
we're
we're
moving
it
to
six
security.
It's
basically
all
ready
to
go
to
go
to
beta
and
like
right
now
we're
just
waiting
on
the
security
chairs
to
accept
it
like
there's
a
pr
up.
They
just
need
to
approve
it
and
I
don't
think
they're
looking
because
this
would
be
their
first
cap
and
then.
A
D
A
A
B
I
think
there
was
one
sorry
one.
There
was
one
kind
of
question
I
I
haven't
been
able
to
follow
up
on
on
this
one
with
satan,
but
maybe
someone
knows
so
one
thing
that
I
was
wondering
about,
especially
for
cloud
providers
like
gke
or
aks
or
pick
whichever
one
you
want.
I
assume
that
people
do
not
have
access
to
the
schedule
or
metrics
right.
How
do
we
envision
this
kind
of
thing
working
with
cloud
providers.
E
B
That's
really
awesome,
I
I
for
me
I
am
a
gke
user.
So
for
me
this
solves
this,
but
I
I
think
I
think
in
particular
with
this
feature
we
may
want
to
go
to
the
cloud
provider
sigs
and
let
people
know
that
this
is
a
feature
that
people
can
only
make
use
of.
If
some,
if,
if,
if
it's
exposed
in
the
same
way
as
gke,
it
tends
to
do
it,
I
I
feel
like
we
may
be,
causing
fragmentation
otherwise,
with
like
dashboard
collections,
rule
collections,
etc.
B
It's
it's
special
because
it's
about
workloads
that
traditionally
always
were
entirely
exposed
by
coop
state
metrics,
and
it
makes
perfect
sense
that
they
are
in
the
scheduler.
They
must
be
in
the
scheduler
because
of
their
nature,
but
like
there's,
the
kubernetes
mixing,
for
example,
that's
like
the
most
widely
used.
So
I.
A
That
has
to
happen
in
the
context
of
that
cap.
There
is
a
pr
up
right
now
to
update
it
for
beta.
I
would
put
that
there
because
we
don't
have
clayton
on
the
call,
and
I
want
to
make
sure
we
don't
get
in
the
situation
of
last
meeting
where
we
don't
discuss
all
the
caps,
because
we've
got
a
few
more
to
go
so.
A
I'm
gonna
skip
this
one
just
because
it's
net
new
for
a
second,
because
I
think
we
can
get
through
the
rest
of
them
faster
and
then
we
can
spend
more
time
on
this
one.
So
I'm
going
to
come
back
to
this
one
structured
logging.
What's
going
on
with
that
merrick,
it's
causing
a
lot
of
review
burden
for
people
like
I've,
seen
in
sig
node
we're
getting
lots
and
lots
of
drive-by
pr's
for
this.
So
I
would
really
like
to
figure
out
a
strategy
for
like
when
we
want
to
get
the
migration
done.
A
D
We
did
not
help
us
to
reduce
like
the
toil
to
to
to
relate
to
reviewing
the
changes
it
would,
I
would
say,
even
like
technically
increase
it,
but
before
like
even
speeding
up,
it's
good
that
I
think
we
are
still
polishing
the
api.
Like
I
would
say
I
what
I
mean
publishing
api,
there's
discussion
that
you
you
had
about
like
the
replacing
fatal
us.
It's
not
no
longer
suggested
and-
and
there
also
was
some
work
on
adding
depth,
so
I
I'm
not
sure,
like
beta
help
moving
to
beta
health
yeah.
I.
A
Mean
maybe
maybe
what
we're
going
to
do?
Is
it's
not
so
much
necessarily
like
I.
I
agree.
This
is
a
really
big
effort
and
I
think
that
you
know
it
may
not
be
feasible
to
do
it
all
in
one
release
to
go
to
beta
and
I
think
that's
fine.
What
I
want
to
see
is
like
some
sort
of
plan
for
like
okay.
We
know
all
of
these
components
exist
in
cube.
They
all
need
to
be
migrated.
Let's
focus
on
we'll
use
these
ones
as
the
beta
testers
and
we're
not
accepting
any
other
structured
logging
prs.
A
So,
like
121,
we
break
all
the
cubelet
logs,
but
we
don't
break
all
the
scheduler
logs
or
something
like
that,
and
that
way
you
know
it's
like
the
review
burden
is,
like
you
know,
isolated
to
one
component.
We
have
a
list
of
like
we
have
to
do
this,
for
this
release,
we're
not
planning
on
graduating
it,
but
we're
continuing
work
and,
like
just
that's,
I
think,
that's
what
we
should
do
at
this
one
we
shouldn't
graduate
to
beta.
I
agree
with
you.
A
I
think
that
it's
going
to
make
it
harder
and
we're
not
going
to
possibly
get
it
all
migrated,
but
I'd
love
to
see,
for
example,
essay
we're
going
to
do
cubelet
to
structured
logging
in
121,
and
we
need
to
like
iron
out
these
kinks
and
then,
like
the
next
release,
we
will
say:
okay,
we're
gonna,
do
all
the
static
analysis,
stuff,
we're
gonna
migrate,
all
the
rest
of
the
components
and
then
that'll
be
our
beta
release.
So
it'll
be
like
a
two
release.
D
Process
yeah,
so
so
I
I
was
thinking
that
moving
like
full
components
or
other
directories
like
talking
full
directories
like
okay,
let's
tackle
everything
under
package
scheduler
should
require
the
static
analysis
piece
because
you
you
just
want
to
say.
Okay
here
are
some
directories:
let's
move
them
one
by
one
and
mark
them
as
ready.
F
A
To
do
the
migration,
so
I
don't
want
to
be
like
oh
well,
it's
out,
but
we
get
all
these
drive
by
pr's
anyways
and
then
people
get
discouraged
because
we
don't
want
to
merge
them
and
then
we
hold
it
off.
And
how
do
you
feel
about
saying
this
is
in
we
don't
necessarily
plan
on
graduating
it
to
beta.
Like
I
mean
I
guess,
what
we
can
say
is
we
can
we
can
put
it
in
as
like.
We
want
to
go
to
beta.
A
C
C
A
Can
potentially
pull
lori
in
to
do
that,
we
might
even
be
able
to
do
that
before
kept
freeze,
but
I
guess
there's
a
bit
of
a
time
zone
challenge
with.
I
think
everybody
that
we
need
to
get
involved
and
there's
not
a
lot
of
days
left
like
I'm
not
working
tomorrow,
so
I
wouldn't
be
able
to
make
a
meeting
tomorrow.
A
A
A
Okay
good,
so
I
think
I
will
put
this
one
back
to
a
question
mark
and
that's
on
me
to
try
to
deal
with
the
scheduling
so
thanks
everyone.
I
think
I
just
want
to
make
this
like
not
super
painful
for
anyone
involved,
especially
not
for
the
project.
The
number
of
structured
logging
pr's,
I'm
getting
as
a
node
reviewer
right
now
is
like
unbelievable.
So
thank.
A
A
I
know
it's
painful,
I'm
sorry,
okay,
so
four,
more
caps,
this
one's
really
easy,
also
I'll,
maybe
jump
to
the
one
on
the
bottom.
So
I
talked
to
wartech
and
also,
I
think
it's
chelsea
chen
who
owned
this
one.
So
this
one
was
graduated
last
release.
We
shoved
it
back
to
beta
because
there's
still
a
bunch
of
stuff
that
hasn't
actually
graduated
yet
like
we
need
to
finish
the
migration.
It's
not
happening
this
release,
though
maybe
next
release
so
that
one's
good.
G
G
A
C
C
A
Yeah,
if
it
slips
it
slips,
that
sounds
good
to
me.
I
think,
and
you
know
everything
you
need
to
do
there.
I
want
to
spend
the
rest
of
the
time,
especially
because
we
have
folks
from
fujitsu
on
the
call
to
talk
about
this
cap.
I
just
want
to
say:
there's
only
one
other
thing
on
our
agenda
and
it
was
me
trying
to
put
something
on
here,
but
org
files
cleanup
and
owners
files
clean
up.
A
We
can
pump
that
so,
let's
talk
about
this
one,
so
I
at
least
the
last
time
that
I
looked
at
this.
I
don't
know
that
this
cap
is
ready
like
in
terms
of
alpha.
We
definitely
need
a
prr
reviewer.
Does
anybody
who
has
worked
on
this
cap
want
to
jump
in
and
talk
about
it
is
there
anything
that
you
have
like
questions
for
the
sig.
H
A
F
A
F
A
Not
implementable,
we
can't
work
on
it
in
a
given
release.
So
if
we're
fine
with
just
you
know,
merging
this
and
saying
we'll
come
back
to
it,
it's
it's
okay
to
leave
it
in
provisional.
But
if
we
want
to
work
on
it
it
has
to
be
implementable.
So
we
are
the
approvers
by
we
I
mean
me
han
david
and
frederick,
the
leads
of
the
sig
and
then
there's
also
one
other
set
of
approvers,
the
prr
or
the
prod
readiness
reviewers.