►
From YouTube: CF on K8s Working Group Forum Meeting 17 May 22
Description
[JH] Removing HNC Proposal - Spike branch
[JH] Logging format: Opinions?
🌈We have a different format for each deployment
Human readable vs. epoch (unix time) vs scientific notation?
CF timestamp proposal RFC3339: CF-RFC 030: Use a Consistent Timestamp Format for Component Logs
Shouldn’t log errors for user RBAC rejection
Scientific notation format?!
Machine readable is convenient - easy to convert to human readable but not vice versa
https://kubernetes.io/blog/2020/09/04/kubernetes-1-19-introducing-structured-logs/
https://kubernetes.io/docs/concepts/cluster-administration/system-logs/#json-log-format
[GC] Great backlog cleanup
If you own an epic that is ‘done’ remove stale stories and put them in another place.
Stories without labels? :(
[RI] INSTALL.md - seems unavailable. Any ETA?
Merged! Thanks for the PR!
[RI] Korifi Press Releases are here!
Cloud Foundry Foundation launches Korifi to simplify the Kubernetes developer experience | TechCrunch
Cloud Foundry Launches New Platform to Simplify Kubernetes Developer Experience
A
A
A
A
B
A
A
Thanks
eric,
so
hopefully,
everyone
had
a
little
bit
of
time
to
skim
the
document
and
get
an
idea
of
what
the
issues
we're
having
with
h
c
are
from
not
propagating
all
the
resources.
We
need
to
a
little
bit
of
slow
reconciliation,
especially
with
clusters
busy
to
the
thought
that
it's
an
additional,
fairly
heavy
weight
external
dependency
and
there's
been
some
work
to
sort
of
spike
out
what
it
looks
like
if
we
can
remove
it.
A
B
D
B
D
Yeah
that
that
is
true,
but
also
it's
not
like
okay,
like
if
it's
it's.
If
it's
something
that
we
know
it's
going,
it's
going
away
soon,
we
might
not
bother
until
then
right
same
with,
like
with
the
radio
status
thing
I
was
wondering
like.
Is
it
something
that
we
can
even
do
given
like
it's
kind
of
supposed
to
be
a
continuous
reconciling
process
like
when
do
we
call
it
done,
I'm
not
entirely
sure
it's
something
that
we
can
even
do.
F
Well,
I
I
think
in
the
case
of
the
custom
like
in
the
case
of
our
bespoke
code,
is
very
straightforward.
Right,
there's
a
very
limited
set
of
things
we
have
to
propagate
it
all
happens
like
near
synchronously
in
our
reconciler.
So
by
the
time
we're
done
reconciling.
We
know
that
this
thing
is
consumable
so
like
that,
isn't
the
guarantee
that
it's
going
to
always
be
consumable
in
the
future,
but
it's
a
pretty
good
guarantee
that
the
that
the
user
who
created
the
org
or
space
or
whatever
can
actually
use
it
right.
F
B
F
B
B
C
I
think
you
could
it's
the
problem's
still
simpler.
Even
for
that
case,
though,
because,
like
you
could
like
not
necessarily
track
all
the
role
bindings
you've
propagated
on
the
resource,
but
you
could
like,
like
tweak,
it
say,
last
updated
at
and
have
our
shim
or
whatever
wait
for
that
to
change
like
I.
I
think
it
does
give
us
a
lot
more
control,
even
for
things
like
that.
G
F
F
F
We
tested
the
configuration
that
we've
imported,
which
means
that
we're
sort
of
taking
on
this
onus
of
of
maintaining
hnc.
You
know
making
sure
that
we're
updated
on
patches
and
things
like
that.
We
have
the
right
image,
references
and
and
we're
in
this
ugly
gray
zone.
Right
now-
and
I
think
most
of
these
solutions
and
mitigations
are
things
that
would
make
that
worse.
F
H
F
H
H
F
F
F
C
C
It's
a
it
basically
says
this
cluster
should
be
used
for
cf
and
cf.
Only
if
you
have
other
name
space
like
management
systems
or
anything
else
like
don't
use
it
versus.
If
we
had
our
own
like
lighter
weight
thing,
it
would
like
shrink
our
footprint
quite
a
bit
and
like
like
widen
the
range
of
like
clusters
and
like
configurations
people
could
like
actually
support,
so
they
could
install
it
alongside
other
things,
easier.
H
D
D
F
So
I,
but
I
I
guess
I
guess,
for
starters,
my
sense,
you
know,
given
the
two
days
of
spike
work
we
did
to
to
run
without
hnc.
Is
that
isn't
actually
going
to
be
that
much
cheaper?
And
then
I
think
going
back
to
what
I
said
earlier.
That
increases
our
footprint
of
hnc
like
mutations,
that
we
then
do
against
an
hnc
configuration
that
we've
got
in
our
dependencies,
not
hnc
in
the
wild
right.
D
B
D
D
So
that's
a
problem
right
if
you
already
have
hnc
for
you,
because
you
want
to
use
it
for
your
own
stuff
and
it's
configured
in
a
different
way.
You
can't
tell
it:
oh,
no
now
listen
all
these
these
spaces
because
they
need
to
use
it
for
something
else
in
a
different
way,
and
that
gets
in
the
way
that
could
be
a
problem.
C
I
guess
and
and
right
and
even
like
a
lot
of
these,
like
levers,
we
have
to
limit
what
it
looks
at
those
are
actually
applying
to
its
like
its
process
itself,
so
the
kate's
api
is
still
like.
Even
if
you
tell
it
only
look
at
these,
like
certain
namespaces
that
match
your
regex,
the
kate's
api
is
still
having
to
like
send
every
namespace
request
to
it,
and
then
the
like
agency
process
itself
decides
whether
or
not
to
use
it.
B
C
C
F
F
D
Do
we
feel
it's
going
to
be
a
lot
easier
like
do
we
feel
our
implementation
is
going
to
be
a
very
strict
subset
of
what
hnc
does
and
thus
is
going
to
be
very
simple
or
like,
because,
if
I
think
of
what
we're
doing
or
what
we're
planning
to
do
versus
what
nhc
does,
I
think
there
is
lots
of
overlap.
So
my
concern
is
like:
are
we
going
to
implement
pretty
much
hnc,
which
is
I
mean,
is
kind
of
it
could
be
a
solution
to
the
hnc
dependency.
D
D
I
don't
know
how
many
people
right,
so
I
I
think
it
makes
sense
to
do
this
if
we
believe
this
is
a
strict
subset
like
a
very
strict
subset
of
what
hmc
does,
which
could
be
the
case,
and
maybe
it
is
but
like
our
cf
space
and
cfo
resources.
Look
a
lot
like
the
hnc
ones
and,
like
the
word,
the
core
behavior
seems
to
be
pretty
much
it
like.
D
I
guess
our
thing
is
going
to
be
a
lot
less
configurable,
so
that
surface
is
definitely
a
lot
tinier,
but,
like
my
concern,
is
that
if
this
is
80
of
the
code
that
is
already
in
hnc,
I'd
still
buy
instead
of
making.
If
you
swear
to
me,
even
if
it's
a
pain
like
I
understand,
I
buy
all
the
arguments
about
it
being
a
pain.
It's
just.
D
I
don't
know
how
much
I
we
would
have
to
decide
decide
if
that
pain
is
so
big
that
it's
worth
literally
rewriting
the
thing
or
rewriting
80
percent
of
the
thing
yeah,
because
then
we
could
argue,
you
know
why
don't
we
do
the
same
for
concur
or
whatever,
like
yeah,
our
other
contour?
Sorry,
the
other
dependencies
like
yeah.
They
are
a
pain
to
maintain,
but
like
they
save
us
work
so
yeah
I
don't
know.
I
guess
I
guess
the
core
point
is:
how
much
do
we
estimate?
D
Is
this
thing
gonna
be
smaller
than
the
real
thing
right
and
we
should
also
another
point
yeah.
I
think
in
favor
of
this
is
that,
in
that
comparison
we
should
not
just
include
the
size
of
hnc,
but
the
size
of
hnc,
plus
all
the
workarounds
we
have
to
put
in
to
make
hnc.
You
know
work
for
us
which
are
not
part
of
agency
itself,
but
things
that
would
go
away
if
we
discard
it
right-
and
I
don't
know
how
easy
it
is
to
evaluate
that.
D
E
F
I
think
that's
kind
of
where
we
are
right.
I
mean
this,
so
the
spike
is
not
complete.
It
only
does
the
propagation
on
on
creation,
not
the
monitoring
and
propagation
of
new
roles
and
whatnot
so
and
it
doesn't
have
a
finalizer,
but
I
think
those
last
two
pieces
are
not
going
to
be
a
ton
of
codes,
so
you
know
it
sort
of
feels
like.
Oh,
I
haven't
looked
at
the
number
of
lines
of
coding
agency.
I
E
F
D
Right
but
those
would,
but
we
could
argue
that
if
those
are
specific
to
our
domain,
then
we
would
have
to
do
something
anyway.
Right,
hnc
doesn't
have
domain
specific
stuff
in
it
for
us.
So
if,
if
there
are
changes
that
will
be
needed
because
they
are
domain
specific,
then
those
I
mean
we
can't
save
on
those.
Those
are
we'll
have
to
do
them
anyway,
if
they
are
specific.
D
Yeah
I
mean
if,
if
we've,
if
we
have
the
spikes-
and
we
believe
that
like
if,
if
I
have
to
choose
between
this
dependency
and
having
like
even
our
50
lines-
80
lines
controller,
I
buy
the
controller
every
day.
Just
because,
like
I
agree
that
80
lines
of
our
own
code
versus
having
a
dependency
that
we
have
to
track,
plus
the
configuration
plus
the
risks
of
conflicting
with
existing
stuff.
D
G
I
mean
but
yeah,
like
you,
said,
we've
covered
what
we
think
is
the
eighty
percent
low
hugging
fruit,
the
obvious
things
that
we
know
about
it's
the
last
20
percent
that
we
don't.
We
haven't
looked
at
things
like
watching
resources
so
that
when
new
role
bindings
appear,
we
replicate
them
so
that
new
admin
users
have
permissions
in
all
the
the
appropriate
name
spaces,
and
that
kind
of
thing
that
we
think
would
be
relatively
straightforward.
And
we've
done
things
like
that
in
the
past.
G
But
that's
where
the
gotchas
could
be,
and
it's
also
the
things
that
we're
not
even
thinking
about
you
know:
we've
looked
at
kate's
roles,
case
role
bindings,
just
the
image
registry
credential
secret.
That
was
the
only
one
that
wasn't
a
service
account
token
that
needed
propagating.
So
that's
the
only
secret
that
we're
propagating
and
then
we
already
had
the
the
service
account
creation
in
the
api,
and
I
think
that's
been
moved
into
the
controllers
now
like
here
and
said,
as
of
1.24.
G
D
B
D
G
D
Yeah,
because,
there's
probably
I
don't
know
edge
cases
in
you-
know
creating
something
then
adding
a
binding,
then
changing
your
mind
deleting
the
binding
who
knows
like
there's,
probably
a
sequence
of
operations
that
breaks
it
but
yeah,
I
think
we're
going
to.
We
can
be
pretty
confident
that,
like
it's
clear
to
us
what
hnc
is
doing
for
us
and
how
we
are
leveraging
it
and
there
shouldn't
be
any
huge
surprises.
I.
B
B
D
We
have
the
advantage
that
our
tree
is
strictly
depth
too,
like
that
they
are
literally
supporting
any
structure,
so
they
support
any
sort
of
on
white
and
wildly
like
tree.
They
support
it.
R1
is
like
fixed
every
yeah.
You
can
have
empty
orgs.
I
guess,
but
like
it's
a
very
flat,
very
regular
tree,
so
that
should
yeah,
maybe
save
us.
Some
headaches
like
we.
D
D
Yeah,
it
should
make
it
easier.
We
shouldn't
have
that,
that's
what
we
save
compared
to
them.
Like
they're,
literally
supporting
the
generic
use
case,
you
can
have
like
a
dab
like
a
hierarchy
of
depth.
50,
if
you
want
it,
does
support
it,
and
maybe
also
the
reconciling
cycle
takes,
takes
that
into
account
right,
like
the
they
need
to
to
be
able
to.
I
don't
know
you
you,
if
you
add
something
at
depth,
25,
you
have
to
replicate
it
all
the
way
down
to
the.
C
Yeah,
it
also
has
a
lot
of
complexity
around
watching
all
the
child
resources
it's
made
and
making
sure
they
don't
diverge
from
anything
in
the
parent.
And
since
we
have
like
a
stricter
subset
of
stuff
that
we
actually
care
about
and
we're
actively
like
preventing
people
from
changing
those
with
our
back
and
stuff.
D
And
we
don't
care
about
name
spaces
being
created
outside
of
like.
If
you
create
a
safe
space,
then
we
reconcile
it
into
a
namespace,
but
we
never
do
things
the
other
way
around
right.
They
don't
either
probably,
but
maybe
that's
more
of
a
problem
for
them
because,
like
once,
you
have
hnc
installed
like
kind
of
every
namespace
is
hierarchical
in
a
way,
so
they
also
have
to
act
on
existing
stuff
to
make
sure
they
can
deal
with
it.
D
B
C
C
E
D
C
C
We're
gonna
want
more
fine
grain
control
over
the
the
various
secrets
and
stuff
that
are
propagated,
because,
like
right
now
you
put
your
registry
credentials
in
the
root
name
space
and
it's
sent
all
the
way
down,
but
like
for
certain
multi-tenancy
like
concerns,
you
probably
don't
want
dev
and
space
a
to
be
able
to
see
the
same
push-pull
secrets
as
devon
space.
Be
right
so
like
like
this.
This
would
give
us
more
power
over
actually
like
letting
operators
set
those
like
on
an
oregon
space
level
and
actually
do
it
better.
B
C
D
Yeah,
that
propagation
from
root
is
kind
of
a
thing
that
we
have
to
actively,
for
example,
replicate
right.
It's
no,
it's
kind
of
natural
in
hnc
to
be
like.
Okay,
wherever
you
put
it
it
propagates
to
the
to
all
children
now,
we'll
have
to
explicitly
say
we
don't
just
have
propagation
from
org
to
spaces,
but
also
from
root
to
orgs
to
spaces.
Potentially,
if
we
want
to
do
it
that
way,
but
maybe
we
don't
even
need
it,
I
don't
know
it
kind
of
opens
opportunities.
That
is
true
for
like
solving
things
just
differently.
F
F
I
think
this
kind
of
reminds
me
of
the
authentication
epic
right
like
where
we
didn't
really
learn
what,
but
it
wasn't
going
to
work
until
we
tried
to
do
it
yeah
so
maybe
yeah.
I
think.
Maybe
that's
the
that's
the
next
step
we'll
see,
and
I
think
it
should
come
clear
pretty
quickly.
If,
if
it
turns
out
that
you
know
there's
complexity,
we
didn't
take
into
account.
A
We'll
certainly
have
a
better
picture
at
that
point,
and
I
think
earlier
on,
the
cost
benefit
is
a
bit
different
than
later.
The
the
opportunity
cost
right
now
is
not
that
large,
it's
a
bit
of
work
to
explore
it
if
it
ends
up
being
difficult
or
problematic
for
other
ways,
then
it's
not
that
much
time
that's
been
used
on
that
and
will
have
a
bit
of
a
more
solid
answer
without
totally
committing
to
it
so
yeah.
I
think
that
sounds
like
a
good
plan.
A
A
So
I
think
that
is
pretty
much
what
we're
aiming
at
that
we,
instead
of
using
this
sort
of
generalized
large
tool,
we
try
to
get
a
more
of
a
scalpel,
so
yeah
cool
any
final
comments
on
this
topic
before
we
move
along
to
the
next
one
and
feel
free
to
sort
of
bring
this
up
in
the
slide
channel.
The
kate's
creepy
dev
channel,
because
you
know
we'll
be
working
on
this
going
forward
and
we'd
love
to
sort
of
find
out.
F
Yeah
I
was
just
starting
to
unpack
an
epic
about
about
logging
and
observability
and
and
doing
some
initial
poking
at
the
logs,
and
we
have
logs
coming
from
mourinho
coming
from
our
controllers,
our
api
shim
and
as
it
stands
today,
our
logs
are
a
celebration
of
diversity,
our
every
possible
time
format,
every
possible
log
format,
some
of
them
are
json.
We've
got
some
sort
of
bosch
format.
B
Should
be,
I've
got
a
couple
of
strong
opinions
that
what
I
don't
like
in
karisi,
so
the
dev
mode
of
the
logging
supposed
to
make
things
easier
to
read.
I
can
read
the
I
think
anyway,
that's
an
aside
because
we
just
switched
that
easily
errors,
that's
it.
So
if,
if
a
user
like
isn't
authenticated
to
do
something,
we
shouldn't
be
logging
that,
as
a
error
level,
that's
the
thing,
that's
generating
a
stack
trace.
That's
just
a
user
error.
We
can
log
in
and
say
user
wasn't
auth.
E
B
Our
application
gets
stuck
and
we
need
to
go
and
print
out
an
error.
That's
that's
the
case
for
an
error,
but
I
think
I've
been
through
all
the
errors
in
the
logs,
and
I
didn't
see
any
which
warning
that
our
our
app
was
broken.
It
was
all
just
the
users
done
something
wrong
really,
so
that
would
be
nice
to
switch
oh
yeah
and
that's
the
dev
mode
thing.
The
definite
makes
the
logs
turn
timestamps
into
like
scientific,
notation
numbers
which
are
absolutely
unreadable.
B
F
H
H
D
I
think
it
was,
I
think
we
began,
we
began
with
timestamps
and
then
people
were
like
you
know
it
does
they're
terrible
like
every
time
we
debug.
We
have
to
copy
and
paste
this
thing
all
over
the
place
to
convert
it.
So
I
think
we
started
moving
towards
like
read
human
readable
timestamps,
but
the
thing
was
configurable,
because
people
wanted
to
maintain
backwards
compatibility,
I
guess
so.
Maybe
we
can
just
start
with
readable
timestamps,
like
some
rfc
format,
that
well
in
terms
of
a
general
format
of
the
logs.
D
E
D
I
actually
liked
it,
but
I
think
nowadays
there
is
like
more
trendy
libraries
that
do
this
as
well,
but
I
think
that's
the
big
choice
like
do.
We
want
to
do
just
line
oriented
or
I
mean
it's
always
line
oriented
I
think,
but
like
do
we
want
to
just
print
json
or
because
I
think
cf's
philosophy
was
we
always
print
json
and
then,
if
you
want
to
read
it
nicely,
there's
a
tool
that
will
do
it
because
in
the
end,
if
you
think
about
it,
you
can
always
go
from.
D
You
know,
well-structured
data
to
any
format
that
you
like
for
reading,
but
you
can't
go
back
if
you
print
something
that
is
nice
to
read,
then
it's
a
pain
to
pass.
If
you
want
to
do
anything
automatically,
like
I
don't
know,
you
know,
monitor
them
or
something
like
that,
it's
just
much
harder.
So
maybe
we
should
go
with
that
and
that
that
feels
like
like
a
good
idea.
I
don't.
B
J
There
is
a
logging
format
that
the
kubernetes
community
follows.
There's
also
been
some
internal
discussion
of
this
at
vmware
and
list
some
larger
subset
of
components.
There
have
settled
on
a
variation
of
that.
That's
basically
like
take
the
fields
in
that
kubernetes
json
log
format,
but
use
the
human
readable
timestamp
instead
of
epoch.
I
guess
we
asked
them
about
that
and
they're
like
I
don't
know
nobody
really.
I
J
F
D
D
D
E
F
E
F
J
Right
yeah,
I
recall
the
I
think
the
go
router
switched
from
the
cloud
foundry
logger
library
to
zap.
Just
for
efficiency.
Blogger
was
not
being
very
efficient
about
serializing
json
and
I
think
it
also
had
some
locking
in
there
that
was
slowing
down
the
go.
Router
so
may
not
be
as
much
of
a
performance
concern
for
us,
but
zap
seems
like
it's
still
used
pretty
widely.
A
A
I
definitely
agree
that
structured
data
logs
are
convenient
because
you
can
always
go
to
human
readable,
as
you
mentioned,
but
the
other
way
becomes
tricky
at
best,
so
yeah.
I
think
we
should
just
choose
something:
a
structured
data
format
and
choose
a
date
format
and
just
go
from
there
because
consistency
over
well,
whatever
we
have.
J
A
D
D
So
what
I'm
asking
you
is,
if
you
own
an
epic
which
you
think
is
done,
go
take
the
stories
that
you
think
are
never
gonna
be
worked
on
in
the
near
future
or
whatever
find
a
new
home
for
those.
Maybe
take
the
label
out
whatever
and
then
put
the
epic
in
done,
so
that
it
doesn't
look
like
we're
working
on
10
epics
at
the
same
time,
which
is
not
realistic.
D
I
do
things
this
by
myself
from
time
to
time
but
like
if
I,
if
I
was
not
the
original
creator
of
the
story,
it's
very
hard
for
me
to
kind
of
trace
back
where
it
comes
from,
and
why
and
whether
it
still
it
makes
sense
if
it
needs
to
go
or
if
it's
something
that
should
be
done
in
the
future.
I
don't
know
like
if
you
do
it
for
the
stories
you
own
it's
much
it's
much
easier.
A
Awesome.
There
is
another
topic
which
is
the
install
md
there's
a
full
request.
This
is
about
our
installation
directions
not
being
up
to
date
and
that
got
wedged
in
our
ci
and
I've
been
trying
to
poke
it
in
the
background
and
it
managed
to
go
through
this
time.
So
I'm
gonna
go
ahead
and
click
that
merge
button
right
now.
A
D
D
A
A
A
Appear
newswire
so
yeah.
Definitely
some
things
to
check
out
definitely
an
indication
that
we're
getting
to
that
point
where
we
feel
like
we
have
something
people
can
look
at
if
we're
publicizing
it
versus
about
a
month
ago,
we're
kind
of
hiding
a
little
bit
so
definitely
cool
to
see
all
that
I
have
not
actually
read
the
article
yet
so
cool.