►
From YouTube: WG Component Standard 20200211
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Okay,
good
morning,
everyone
welcome
to
the
tuesday
february
11th
working
group
component
standard
meeting-
I'm
excited
about
today,
because
america
is
going
to
be
presenting
the
structured
logging
cap.
So
you
know
that's
generated
a
lot
of
discussion
and
you
know
could
be
some
pretty
cool
improvements
to
our
logging
subsystem.
A
Yes,
you
want
to
maybe
share
your
screen
and
take
it
away.
B
B
B
Okay,
so
what
are
the
current
goals
of
structured,
open
caps?
So,
overall
we
want
to
so
currently.
Locks
in
kubernetes
are
like
our
free,
normal
or
old
format,
based
login,
which
leaves
a
lot
of
like
they're,
not
very
guided
they're
pretty,
like
I
know,
if
chaotic
they're,
not
very.
B
Not
very
like
organized
or
they
like,
to
really
like
structure.
So
this
means
that
they're
very
hard
to
query
and
they're
very,
like
they're
expensive,
to
start
because
it's
hard
to
query
because
you,
you
basically
need
to
already
know
and
understand
log
lines
that
you
want
to
find
and
you
and
when
starting,
you
basically
always
need
to
have
full
text
search
based
on
and
you
need
to
index
full
like
text
fields.
B
B
So
we
are
mainly
focusing
on
on
really
how
high
volume
locks,
so
we
are
targeting
to
like
three
nines
of
percent
of
flux,
volume
to
be
corrected,
which
translates
barely
like,
basically
to
nine
to
about
20
log
lines
or
log
calls
to
into
logging
api
or
login
login
library.
B
So
this
is
like
over
like
our
goals
in
migration.
So,
at
the
end
we
by
this
cap
would
like
we
would
introduce
a
new
you
know,
interface
or
new
methods
that
would,
instead
of
having
formats
like
logs,
having
a
more
structured
like
interface,
which
means
having
a
normalized
message
that
and
all
those
arguments
to
the
log
having
separated
and
each
of
them
having
been
named.
B
So
maybe
I
will
so
like.
This
is
example
of
the
the
api
that
we
want
to
introduce
and
by
changing
those
logs
into
new
api,
we
are
expecting
to
improve
overall,
improved
message
in
text
format.
B
So
one
of
the
one
of
the
problems
that
we
also
want
to
solve
is
that
is
the
inconsistency
of
referring
to
kubernetes
objects.
So
if
you
look
into
like
current
logs,
there
are
lots
of
ways
like
usually
every
at
least
for
pot.
You
can
see
as
many
reference
to
but
only
pod
name
and
as
many
to
using
both
namesace
and
squadron,
and
this
is
like
only
looking
at
the
bots
they're.
I
think
they're
like
it's
harder
to
automatically
gather,
but.
B
It's
there
is
no
one
like
obvious
way
that
that
it
should
be
done
so
as
additional
change.
We
want
to
maybe
define
a
list
of
or
defined
how
kubernetes
objects
should
be
represented
in
in
log
in
in
locklands
and
possibly
create
a
module
or
set
of
utility
functions,
or
there
was
recently
proposal
to
build
it
in
into
a
logging
api.
B
B
So
originally
the
so
michael
asked
me
to
to
present
it
because
originally
we
were
not
sure
where
to
put
the
configuration
and
of
the
logging
and
also
we
were
unsure
where
to
put
this,
so
we
called
it
metadata
package,
so
this
set
of
like
functions
that
would
handle
formatting
the
objects
like
references
to
objects,
so.
B
We
within
current
proposal,
we
are
thinking
about
adding
possibility,
or
within
this
cap
we
we
want
to
have
at
the
end
of
it.
Two
working
logging
formats
that
could
be
that
will
be
separate
like
supported
and
will
have
some
will
be
independent,
and
we
also
we
want
to
for
future.
We
want
to
like
leave
ability
to
expand
those
in
the
choice
of
logging
format
or
even
allow
people
to
implement
their
own,
and
this
as
a
as
a
this
configuration
options
and
like
we.
B
We
think
that
this
could
be
shared
between
all
the
components,
so
I
think
yeah
michael
suggested
that
we
should
put
it
as
part
of
component
base,
so
people
can
start.
We
can
start
standardized
logging,
configuration
and
logging
formats
there.
A
Yeah,
I
think
I
think
you
know,
I
think
it
could
be
a
good
idea
to
put
it
in
component
base.
I
think
there's
possibly
some
nuance
around
it
like.
If
you
know,
if,
if
you're
mostly
making
changes
to
k
log
right,
then
maybe
it
makes
sense
to
just
for
just
to
be
with
k.
Log
like
k,
log
is
kind
of
in
some
ways
unique
in
that
it's
separate
from
everything
else.
A
As
far
as
the
repo
structure,
whereas
a
lot
of
other
things
like
this
gone
into
component
base,
and
I
don't
think
we
would
add,
k
log
to
component
base
just
because
of
how
big
a
change
that
would
be
so
you
know
I
could
see.
For
example,
if
you
know
there
were
options
on
k
log,
but
then,
like
maybe
some
like
more
advanced
options
that
we
still
wanted
to
be
common
across
our
components.
B
Yeah
like
originally
this
proposal
like
had
much
bigger
scope,
and
we
were
thinking
about
replacing
payload
and
with
some
generic
interface.
So
here
we
like
for
sure
we
are
thinking
about
like
having
that
component,
but
I
think
there
is
still
big
interest
into
doing
it
in
the
future.
B
So
I
think
I
I
left
it
in
future
future
work,
which
is
propose
a
replacement
for
k-log,
and
this
is
something
that
is
really
interes,
something
that
release
solid
ross
and
tim
hawking
are
working
on
for
a
long
time,
so,
basically
replacing
internals
of
k
lock
with
generic
interface.
That
could
be
that
doesn't
depend
on
any
implementation
and
then
having
and
then
after,
like
with,
firstly,
k,
lock,
internals,
replaced
then
and
structured
logging.
B
We
could
then
switch
to
new
interface
and,
like
this
interface
could,
like
component
base,
looks
like
a
like
best
place
to
like
to
have
the
implementation
to
have
of
those
of
those
of
the
of
this
interface,
and
this
was
like
originally
suggested.
B
That
makes
sense
to
me
yeah,
yes,
so
here
with
the
main
goal,
so
main
goal
of
these
changes
is
not
only
like
to
improve
this
interface,
but
also
make
logging
in
kubernetes
not
like.
So
if
you
develop
your
own
component
and
you
want
to
use
kubernetes
standard
logging
and
use
skylock,
you
then
get
huge
baggage
of
dependencies
that
you
need
to
install
that
are
just
like
transients
dependencies
on
dependencies
that
you,
you
don't
care
and
don't
want
to.
B
A
B
A
Yeah,
so
I
think,
there's
there's
two
places
we
can
really
fit
in,
like
one
is
just
the
expertise
in
the
working
group
as
far
as
like
doing
things
across
lots
of
components
and
sort
of
project-wide
refactoring
work
and
then
the
the
other
places
you
know
once
you
sort
of
really
have
your
plan
together
of
like
these
are
the
changes
we
need
to
make
like
it's
easy
for
us
to
find
people
who
can
go,
do
sort
of
simple
updates
to
the
code
base
so
like
we
can
help
you
like
get
people
to
work.
B
So,
with
current
plan,
we
are
not
like
our
goal,
for
this
gap
is
to
do
like
so
original
migration
proposed,
but
this
kept
would
be
pretty
small
because
we
want
to
like.
B
We
want
to
only
focus
on
introduction
of
new
api
and
like
big
impact,
like
big
results
in
logs.
So
of
course,
there
will
be
later.
The
the
the
next
step
after
this
cap
is
teaching
or,
like
writing
user
guides
and
teaching
like
contributors
to
use,
to
use
this
new
interface
and
how
to
use
it,
and
that
would
be
the
I
imagine
that
would
be
pre
case.
That
would
need
pretty
nice
like
to
scale.
A
Okay,
yeah
well,
just
for
you
know
we're
a
resource
when
you
need
us.
So
please
keep
that
in
mind.
We
can
try
and
make
this
happen
faster
once
you're
ready.
I
think
I'm
pretty
satisfied
with
the
current
cap.
I
need
to
go
through
and
do
you
know
one
more
pass
at
it,
but
I
think
I
think
what
I'm
comfortable,
if
other
people
are
comfortable
with
it,
because
it's
had
so
much
debate
already.
B
So
so
I
think
that
most
of
the
debate
was
on
like
having
opinionated
this
idea
about
how
locks
should
look
like.
So
we
try
to
move
it
out
of
the
scope
of
the
cab
because
we
don't
want
to
want
to
tackle
the
opportunity-
and
second
was
about
discussion
about
amount
of
work
that
we
needed
to
do
so.
We
needed
to
address
that,
but
the
so
exact.
B
Idea
how
to
utilize
how
to
yeah,
I
think
work
between
other
components
is
like
after
thought,
so
I
was
really
keen
to
having
to
making
sure
that
this
this
makes
sense.
The
component
for
component
base.
A
Yeah,
I
think
it.
I
think
it
does
make
sense,
and
I
definitely
think
we
want
a
common
set
of
options
for
logging
across
all
components
and
that's
going
to
be
things
like
verbosity
and
the
format.
And
then
I
don't
know
if
there's
if
there's
too
many,
probably
like,
where
you're,
where
your
logs
are
going,
whether
you're
sending
them
to
a
file
or
standard
out
are
like
the
three
major
ones.
C
Yeah
chris
hein-
and
I
were
just
talking
about
how
controller,
runtime
and
builder
decided
not
to
use
klog
as
well,
and
a
lot
of
that
was
just
based
on
the
usage
of
time
stamps.
So
like
yeah,
allowing
folks
to
configure
these
things
in
a
sensible
and
more
discoverable
way
is
totally
in
our.
A
A
good
interest
but
yeah,
I
I'm
I'm
happy
to
put
the
common
set
options
in
component
base,
especially
if
that,
if
you
think
that
makes
it
easier
to
move
to
like
a
more
generic
interface
down
the
road
and
have
component
base,
be
the
concrete
implementation
of
that.
That's
fine.
B
So
I
think
it
would
so
I
have
like,
I
think
we
can
approach
like
the
configuration
in
two
ways.
So
we
because
there
are
two
parts
to
to
like
to
to
configure
those
two
two
logging
formats.
So
one
is
we
need
to
have
a
common
flag
and
and
picking
a
mechanism
for
some
implementation,
which
also
means
that
there
needs
to
be
some
registry
that
people
can
register
their
implementation.
B
A
B
A
A
Yeah,
like
there
probably
needs
to
be
a
like
an
opt-in
to
the
new
new
way
of
configuring
logging
right
and
then
a
standard
translation
from
these
new
options
to
k
logs
options.
B
So
we
could,
I
don't
know
technically
we
could
like
this
is.
This
was
my
my
idea
because,
like
you
said
you
don't
use
k
log
so
having
like
full
having
implementing
this
suit
like
decision
about
switching
the
configuration
would
require
you
to
somehow
depend
on
k-log,
and
but
we
can.
B
A
I
think
that
sounds
okay
to
me,
I
mean
we.
We
can
look
at
how
big
it
would
be.
It
may
already
be
imported
in
component
base.
I
wouldn't
I
wouldn't
necessarily
be
surprised
if
it
was.
I
just
don't
think.
We've
explicitly
stated
that
anywhere
yeah
and
I
think
the
other.
The
other
piece
here
is
when
we
add
this
logging
config
structure
like
that
is
also
the
standard
structure
that
needs
to
be.
B
A
Logs
and
then
we
probably
need
a
way
to
opt
in
to
choosing
to
use
that
new
substructure
or
falling
back
to
like
the
old
flags.
That
catalog
was
registering.
B
A
Yeah,
okay,
I
think
our
concern
would
be
like
making
sure
that
the
helpers
to
set
all
that
up
are
implemented
in
a
common
place
so
that
each
component
isn't
left
to
its
own
devices
to
figure
out
how
to
wire
these
things
together.
B
A
Okay,
cool,
oh
the
other
thing,
so
the
helper
methods
for
producing
the
consistent
resource
identifiers.
A
That
sounds
like
something
that
might
be
more
appropriate
for
api
machinery
than
component
base,
since
it's
sort
of
close
to
that
metadata
concept
in
api
machinery.
A
A
I
don't
know
if
that
is
if
we
would
want
to
just
default
to
that
or
if
we
really
want
it
to
be
specific
to
each
like
a
different
key
for
each
object
kind,
I'm
not
sure,
just
a
different
key
for
a
different.
You
know
each
kind
is,
is
you
know
sufficient,
because
the
api
groups
act
as
name
spaces
for
kinds,
and
so
you
could
in
theory,
have
the
same
kind
name
in
two
different
api
groups.
C
B
We
want
to
be
able
to
put
call
like
put
be
able
to
put
object
cover
like
some
kubernetes
object
and
having
clogging
having
like
ready
methods
or
some
internal
login
parts
to
figure
out
how
it
should
be
represented,
and
so,
but
so
this
is
like
our
hour
long
from
started
logging
for
current
problem
that
we
are
attacking
for
the
text
logs.
We
just
want
a
sim
something
simple
that
is
obvious
and
uniform.
A
Like
I
wonder
if
you
want
for
queryability,
if
you
want
it
to
just
all,
be
compact
in
a
string
or
if
you
actually
want
to
split
each
metadata
field
out
into
a
separate
key.
B
B
C
B
Try
to
figure
like
think
about
this,
so
for
us
like
for
text
blocks
we
we
are
not
investing
too
much
into
it,
because,
though
I
assume
like
like
you
can
go
like
as
far
and
to
complicate
like
your
your
logs,
we
are.
This
is
much
more
interesting
topic
for
extract
for
log
json
based
logs,
okay,.
A
Okay,
I
see
it's
split
out.
How
does
how
does
metadata.pod
know
to
split
that
out
for
a
structured
log,
but
not
for
a
unstructured
log.
B
So,
if
I
remember
correctly
so
this
would
be
part
of
implementation
of
k-log,
so
metadata
pod
would
return
object.
That
or
dedicated
structure
that
would
include
object,
maybe
or
object
reference
or
specific
object,
like
logger
logging,
dedicated
reference
to
object
and
then
based
kk
log
would
either
use
the
string
method
on
it
or
triangle
strings
by
end
result
in
this,
or
we
could
use
some
either
json
or
our
like
orn
formatting,
to
put
like
like
or
try
to
always
convert
to
json.
If
we
get
our
expected
types,
okay,
that
makes
sense
yeah
but
yeah.
A
Yeah,
it
would
be
nice
to
just
pass
in
a
pod
and-
and
they
should
all
support,
like
the
there's,
like
an
object.
Interface.
B
A
A
But
if
you
were
wanting
to
try
and
detect
if
an
object
that
got
passed
in
was
a
kubernetes
object,
you
could
try
and
do
that
it
may
be
limited
to
like
what
is
registered
in
the
scheme
that
your
login
implementation
is
aware
of
as
far
as
detecting
that
schema.
So
it
might,
I
don't
know
how
complicated
this
would
get
or
how
slow
yeah,
but
we
could
look
at
it.
B
From
feedback
from
voitec,
I
don't
think
like.
There
is
a
bigger
problem
than
this,
because
apparently
k-log
loses
lots
of
time
on
the
calculating
or
doing
runtime
recognition
of
formatting
and
then
noticing
that
logs
should
not
be
generated
because
of
verbosity
set.
B
So
second
problem
would
maybe
be
more
from
team
team
hacking
that
there's
we
would
want
to
have
maybe
api,
that
is
generic
and
not
kubernetes,
kubernetes
kubernetes
our,
but
maybe
we
should
think
about
how
we
can
solve
it
differently.
So
when
I
mean
like
we
could
either
put
this
logic
into
to
do
it
by
client
that
uses
the
library
or
either
put
it
within
the
logging
library,
and
it
would
be
just
a
design
decision
where,
like
if
the
ap
logging
api
should
be
kubernetes
aware.
B
A
So
what
is
what
is
the
overall
migration
plan?
Now,
like
we
get
these
new
methods
in
place,
we
tell
people
to
start
using
them.
Are
we
going
to
organize
an
effort
to
you
know
redo
all
the
existing
logging
as
well.
A
B
B
B
Maybe
try
to
communicate
like
maybe
to
do
different
things
about
like
new
login
guides,
and
but
currently
there
is
no
like
concrete
plans
required
to
do
for
for
to
organize
this,
mainly
because
how
many
people
we
throw
out
the
problem
or
how
many
automation
we've
write
to
solve
this
problem,
the
bottleneck
would
be
the
review
sure.
A
I
think
we
can
find
a
few
reviewers
in
this
group,
at
least
to
help
share
that
burden.
I'm
happy
to
review
the
like
it
seems
like
they're.
They
would
typically
be
pretty
simple
prs
to
review,
because
it's
just
you
know
every
log
line
change.
It's
a
one
line,
change
like
for
each
thing
right.
It's
like
I'm!
A
I'm
changing
from
this
method
to
that
method
like
check
that
the
same
information
got
plumbed
and
it's
pretty
uniform,
you
could
even
probably
write
a
style
guide
and
just
tell
reviewers
like
just
make
sure
it
matches
the
style
guide
and
that
this
is
the
term
the
transformation
we
expected
and-
and
I
think,
you'd
get
through
review
pretty
quickly.
B
Yeah
but
it
so,
we
want
to
make
it
like
pretty
natural
progression
based
on
like
style
guides
and
maybe
some
nudging
of
contributors
to
use
it
and
and
try
to
monitor
how
much
so
try
to
detect.
When
is
the
point
where
we
will
be
committing
to,
we
will
be
committing
to
out
maybe
automatic
migration.
So,
for
example,
when
we
get
90
percent
of
locals
in
the
new
api-
and
we
know
that
those
are
really
miniscule
like
those
generator
really
mini
skill
number
of
log
lines.
A
Okay,
yeah,
you
may
like
okay.
I
agree
it's
too
early
to
figure
this
out
right
now
and
we
shouldn't
block
you
developing,
like
the
newer
pieces
of
this
logging
library
on
that.
So,
yes,
we
should
merge
this
cap.
I
think
that
we
maybe
want
to
do
it
sooner
than
90
percent,
but
we
can
discuss.
B
New
feedback
from
developers
about
new
api
people
using
maybe
json
or
we'll,
see,
then
what.
A
Are
people
happy
with
it
sounds
good.
I
think
we're
we're
like
10
minutes
over
here,
but
so
thank
you
so
much
for
coming
and
presenting.
I
think
that
was
really
useful
for
us
and
helpful
for
our
understanding.
B
A
Take
another
pass
at
the
cap
this
week
get
my
ltm
I'm
excited
about
it.
Yeah.