►
Description
2022-07-12
[JH] Code Climate: we don’t appear to have access to mark issues as “wontfix” in AMER. Maybe we need to set some team membership?
Go to User Settings - GitHub
Grant Access public repos
In the dashboard, add cloudfoundry/korifi
[PC] cf-for-k8s deprecation strategy
Notify on cf-for-k8s README in repo
Direct to Korifi as possible migration path
IAAS reduction
Maintenance window (3-6 months?) before full switchover
https://lists.cloudfoundry.org/g/cf-dev/message/9371
[TD] This describes we will only be doing maintenance updates. Stopping maintenance updates will be a change
Get community feedback to put features on roadmap.
Cf-dev message - perhaps tie with Korifi release?
[DB/KB] shim API logging improvements
[JH] related to this github issue? (not exactly. It has some overlap but doesn’t address log format, so we will still need the separate issue.)
PR for log severity: https://github.com/cloudfoundry/korifi/pull/1356
[GC] Next EMEA epic?
TaskWorkload is a high value target
Tim can flesh out label/annotation proposal/stories to provide runway while Giuseppe generates a proposal for TaskWorkloads
Role resource? CFRole Custom Resources
[JH] Validation versus reconciliation for CFSpaces
[CC] Kubecon CF pre-event! Tuesday before Kubecon starts
CFP for this will happen soon
A
Awesome
good
morning,
good
afternoon,
good
evening,
wherever
you
are
welcome
to
the
bi-weekly
cloud
foundry
on
kubernetes
working
group
form
meeting,
there
is
a
notes
document
that
I
will
be
pasting
in
chat
for
everyone
to
add
topics
to.
If
you
have
any
that
you'd
like
to
add,
please
drop
them
in
there
or
otherwise.
You
can
drop
them
in
the
zoom
chat
and
I
can
manually
add
them
myself.
A
We
have
a
few
topics
on
there
already
looks
like
about
three
or
four
of
them,
so
if
you
have
any
more
to
add,
do
so,
but
we're
going
to
get
rolling
on
the
first
one.
So
the
first
one
is
a
code
climate.
We
don't
appear
to
be
to
have
access
to
market
issues
as
won't
fix
and
the
american
side.
Maybe
we
need
to
set
some
team
membership.
D
C
D
A
D
E
F
D
D
A
A
So,
as
people
have
maybe
noticed,
and
we've
talked
about
a
little
bit
over
the
past
several
months,
seaford
gates
has
been
in
a
sort
of
feature:
freeze,
mode,
maintenance
mode
where
we've
been
pretty
much
focused
on
just
remedying
some
cvs
and
whatnot,
but
not
actually
doing
active
development
on
it.
While
we
focus
more
on
the
sort
of
newer
generation
in
karify,
and
so
as
part
of
that,
we
need
to
figure
out
what
we
actually
want
to
do
to
sort
of
put
in
the
freezer.
So
to
speak.
A
I
think
the
biggest
things
for
my
point
is
probably
to
produce
a
new
set
of
images,
just
to
sort
of
make
sure
everything's
up
to
date
and
publish
that
as
sort
of
a
batch
release
as
well
as
mark
on
the
repo
that
it
is
in
pretty
much
just
maintenance
mode
at
best
and
they're
also
sort
of
link
people
to
karify
and
other
things.
And
then
the
the
follow-up
is
anyone
that
is
a
current
user
of
cf
for
kate's.
A
G
My
only
thought
was
just
like
a
plus
one,
because
it's
like
I
saw
last
week,
seth
mentioned
hey,
bump
your
ruby
and
your
your
cloud
controller
image
because
we're
on
ruby3
I
was
like
wait
a
second.
We
haven't
pumped
cloud
controller
since
september
2021,
so
that
that
new
ruby's
not
gonna
work.
So,
like
I,
I
think,
even
though
we
are
like
keeping
up
to
date
for
like
istio
and
uaa
and
stuff,
it's
like
still
like
the
fact
that's
just
lingering
out.
There
is
actually
a
negative
for
the
community,
so
this
is
positive.
C
C
F
A
H
And-
and
I
think
for
me
too
like
it
might
just
be
good
to
whether
we
do
it
in
this
doc
or
not-
I
don't
know
like
but
come
up
with
like
here,
are
the
whatever
six
things
we
want
to
make
sure
we
do
potentially
in
in
order
roughly
that
says.
Okay,
like
you
know,
we
want
to
put
notifications
on
the
repos.
We
want
to
put
notification
whatever
I
don't.
You
know,
I
think,
calling
that
stuff
out
like
as
an
itemized
list
will
be
really
helpful
to
be
like
okay,
cool.
H
I
I
mean,
I
would
say
you
know
once
you
put
it
out
to
the
wider
community
and
just
as
long
as
you
let
people
know
as
soon
as
possible.
I
think
that's
great.
I
mean
if
you
can
give
people
six
months
or
some
nice
comfortable
chunk
of
time
before
you
cross
over
and
stop
maintaining
cf
kids,
that's
great,
but
maybe
less
is
fine
too.
Just
I
put
something
on
cf
dev
and
in
the
general
slack
and
just
kind
of
let
everyone
know
what
the
thinking
is
and
we'll
see.
H
Makes
sense
well-
and
I
know
that
we
we
did
an
announcement
last
year-
that
we
were
gonna
start
reducing
support
for
it.
So
you
know
I
you
know,
I
don't
know
how
much
of
a
backlash
there
was
at
that
point
or
response,
but
you
know
I'm
wondering
if
that
would
count
as
part
of
our
quote
unquote
six
months,
even
though
I
know
that
was
just
a
suggestion.
I
H
I
I
I
J
I
guess
the
only
other
thing
that
I
wanted
to
ask
was:
can
we
be
open
and
straightforward
about
kurifi
being
like
the
de
facto
replacement
for
cf4
gates?
Is
that
a
statement
slash
positioning
that
we
want
to
take
and
call
that
out
explicitly
on
our
docs
in
our
announcements,
etc,
because
giving
people
an
alternative
and
providing
the
path
towards
migrating
to
that,
I
think,
will
make
the
whole
announcement
a
little
more
palatable.
So
I
just
wanted
to
clarify
about
that
and
ask
what
people
thought
about
it.
C
D
So
we
need
if
we
want
to
do
that,
we
need
to
clarify
and
we're
not
there
yet,
probably
just
because
the
starting
points
were
very
different,
like
we
are
rebuilding
a
thing
from
scratch
over
here.
So
it's
going
to
take
a
bit
longer
to
get
to
the
point
where
cf
gates
was
because
yeah
for
kids
was
recycling
existing
components,
so
by
definition
but
other
than
that
yeah.
I
think
it
makes
sense.
I.
D
Forget
was
never,
I
guess
we
released
one,
or
is
that
maybe
you
might
have
sent
sort
of
a
message.
I
don't
think
it's
that
big
of
a
deal
to
say
you
know
we're
replacing
something
that
was
potentially
more
stable,
more
future
complete
with
this
new
thing,
because
we
think
we
thought
it
was
the
good
thing
to
do.
D
I
mean
it
would
have
been
a
bit
weird
if
the
thing
we
were
replacing
where,
like
super,
stable
and
super
used,
and
suddenly
we
chuck
it
away
for
something
that
is
not
comparable
but,
like,
I
think
several
gates
wasn't
that
I
didn't
have
that
big
of
an
adoption
to
begin
with.
So
even
if
we're
doing
this
trend,
what
feels
like
a
kind
of
a
step
back,
you
know
in
order
to
make
two
steps
forward,
then
it
doesn't
feel
that
big
of
a
deal.
J
D
D
J
H
Yeah-
and
I
think,
in
terms
of
like
step
forward
step
back
right
like
one
of
the
things
I
think
we
want
to
be
clear
about
is
while
it
may
be
a
step
back
at
the
moment
in
terms
of
features,
this
is
a
step
forward
in
the
terms
of
like
architecture
and
technology,
and
things
like
that.
It's
the
right
direction-
it's
just
you
know
recreating
all
of
cloud
foundry
on
top
of
kubernetes
is
not
a
small
task
right.
So.
D
H
Yeah,
as
I
say,
I
think
those
gaps
are
great
places
to
to
be
like
to
recommend,
engagement
and
and
making
sure
like
hey.
If
this
is
something
that
you
need,
you
know
we
get
it
on
the
roadmap.
You
know
I
mean
we
planned
for
it.
Okay,
you
know
understood,
you
know
whatever
it
is
that
you're
looking
for
it's
not
there
yet,
but
based
on
community,
need
we'll
we'll
get
it
on
the
roadmap,
so
yeah.
That
makes
sense.
A
A
D
A
E
D
A
A
C
So,
for
the
last
couple
of
days,
we've
been
working
on
some
various
improvements
on
api
logging
extracting
common
bits
here
and
there,
but
most
importantly,
first
we
aligned
the
lock
level
the
severity,
the
severity
level
for
block
entries
so
that
until
like
this
is
still
pr.
But
if
you
look
at
the
api
locks,
you're
going
to
see
a
bunch
of
errors
with
stack
traces
which
are
actually
expected
states
of
the
system,
for
example,
the
user
provided
wrong
input,
which
is
not
an
error
from
point
of
curif.
C
We
also
improved
the
logging
of
the
requests,
so
we
used
to
have
the
correlation
ids,
which
correlates
various
requests.
But
now
you
can,
when
you
collect
for
a
correlation
id,
you
can
see
the
incoming
request
details
like
url
method,
and
you
can
also
see
the
response.
How
much
time
did
the
processing
of
the
request
take
so
looks
pretty
neat.
C
C
B
C
B
B
H
D
E
B
F
C
C
F
A
D
Yeah,
so
we
are
very
close
to
finishing
the
tasks
work.
I
think
we
have
like
two
ongoing
stories
plus
three
in
the
turo,
so
I
expect
it
to
be
done
soon.
So
I
started
thinking
about
the
next
thing
and
there
were
a
couple
of
ideas,
a
couple
of
proposals.
One
was
doing
the
work
on
the
annotations
and
labels
across
all
resources,
and
my
understanding
is
that
there
is
already
a
proposal
for
that.
D
So
maybe
I
wanted
to
hear
from
people
who
wrote
the
proposal.
Slash
have
context
on
the
proposal
to
see
if
how
you
feel
how
ready
you
feel
it
is
for
us
to
just
turn
into
stories
and
pick
up,
and
the
other
thing
would
be
maybe
accelerating
on
the
task
workload
work
so
that
we
can
finish
the
irini
assimilation
and
in.
B
D
D
We
get
to
rewrite
that
kind
of
old
code
and
we
get
some
consistency,
because
now
we
have
some
things
done
via
the
new
components,
something
still
done
by
the
old
components,
but
that
one
would
take
a
little
bit
longer,
because
I
would
have
to
write
a
proposal,
although
I
could
probably
borrow
a
lot
from
the
existing
from
the
other
one,
the.
What
is
it
called
the
run
workload
they're
probably
going
to
look
very
similar
and
then
write.
All
the
stories
feels
like
a
bigger
chunk
of
work.
D
So
maybe
one
thing
that
could
make
sense
is
if,
if
it's
quicker
to
come
up
with
the
label
and
annotation
stories
do
that
and
while
the
team
is
working
on
those
stories,
I
work
on
the
proposal
and
stories
for
the
tasks
stuff
or
the
alternative.
Is
I
just
start
straight
away
with
the
tasks,
because
it's
it's
more
stuff
to
do
so.
This
one
are
the
better,
so
we
just
wanted
to
gather
opinions
and
then
I
guess
we'll
decide
which
way
to
go
or.
B
D
There
is
any
other
epic
that
you
think
should
be
started
or
any
other
proposal
that
is
sitting
there.
That
could
be
worked
on
or
maybe
stories
in
the
u.s
backlog
that
could
be
picked
up.
Anything
like
that
any
ideas,
because
soon
our
to-do
is
going
to
be
pretty
much
empty.
I
mean
it's
going
to
be
just
chores.
I
guess
so.
We
need
to
find
stuff
to
do
and
it
would
be
nice
to
have
some
feature
work
because
yeah
we
can
do
chores,
but.
G
So
I
wrote
the
labels
and
annotation
proposal.
I
haven't
I've
made
an
epic,
but
I
haven't
started
writing
the
stories
for
it.
I,
I
honestly
think
the
task
workload
consolidation
is
more
valuable
and
probably
better
for
interesting
and
and
work
to
be
done.
The
labels
and
annotation
stuff
to
start
with
is
just
like
pure
crud,
like
work
like
it's
like
adding
additional
fields
to
some
of
our
json
structs
and
like
just
like
implementing
a
few
new
patching
points
that
accept
them
for
for
resources.
So
it's
I
can.
D
Yeah,
I
was
thinking
of
it
as
a
something
to
to
give
me
some
time
to
work
on
the
meteor
proposal
and
the
story
right
because,
like
for
tasks,
what
I
thought
was
actually
a
very
quick
and
straightforward
epic
took
me
a
long
time
to
write
the
proposal
and
then
to
write
old
stories
and
the
more
I
wrote
stories,
the
more
I
realized
I
was
missing
stories
and
kind
of
exploded.
I
think
this
is
going
to
be
the
same
yeah.
D
G
Yeah
yeah,
I
can
start
making
stories
for
it
so
like
for
context.
I
I
wrote
a
lot
of
the
stories
and
did
the
like
epic
or
whatever
you
want
to
call
it
for
for
cloud
controller
for
the
same
track
of
work
for
it
and
the
team
back
then
burned
through
them.
Very
quick,
of
course,
that
was
ruby
and
you
could
just
like
write
a
module
and
import
it
and
get
the
behavior
everywhere.
But
it's
it's
still.
G
It's
just
like
pure
crud
at
this
point,
because
we're
deferring
the
actual
propagation
and
stuff
to
a
future
epic
to
decide
where
that
makes
sense
and
if
there's
any
kind
of
allow
or
deny
lists
of
labels
to
propagate
and
stuff.
So
this
one
is
just
like
you
accept
them,
put
them
on
the
cr
and
then
read
them
back
out,
but.
D
Yeah
or
I
can
do
that,
acceptance
is
going
to
be
fun.
I
guess,
and
just
go
through
every
single
resource
on
the
system
to
see
that
it's
actually
properly
doing
whatever
it's
supposed
to
do,
but
I
guess
it
has
to
be
done.
So
it's
not.
It's
gonna
be
a
bit
tedious,
but
that's
the
nature
of
it.
Okay.
So
these
cross-cutting
things.
G
G
E
We'd
also
been
julian.
I
know
you've
been
working
on
a
proposal
about
a
specific
like
cf
role,
resource
that
would
encapsulate
a
bunch
of
the
role
permissions
that
we've
been
associating
to
orgs
and
spaces.
I
know
that's,
maybe
a
little
bit
more
nebulous
right
now,
but
it
could
be
another
area
to
be
working.
B
B
D
B
D
A
D
Equivalent,
so
I
guess
we
should
be,
we
should
have
some
context
on
the
code
side
as
well,
but
after
that,
because
again
like
it
really
depends
on
how
long
these
things
take
the
I
think
the
run
workload
and
the
build
workload
epics,
I
feel
like
it.
They
went
through
relatively
quickly
like
I
don't
know
if
it's
just
because
we
are
not
the
ones
doing
them,
but,
like
I
kind
of
saw
them
pass
by
quite
quickly,
so
it
might
be
the
same
for
tasks.
I
don't
know.
B
D
E
E
Coming
back
to
the
labels
and
annotation
proposal,
I'll
drop
a
link
into
that
I
mean
it
was
looking
pretty
complete
to
me.
I
know:
there's
some
discussion
at
the
bottom
about
any
potential
concerns
about
security
or
reserve
labels,
but
is
it
correct
that
we're
just
at
this
point
since
we're
not
really
propagating
any
labels?
We
just
kind
of
kind
of
want
to
document
things
that
are
reserved
for
cf
usage
and
otherwise
keep
it
unrestricted.
G
Through
our
controllers
that
make
these
underlying
resources,
then
it
should
continue
to
be
safe
and
then
we'll
have
more
control
over
like
what's
reserved
and
what's
not
and
stuff.
So
so
that's
my
my
thinking
around
there
right
now
that,
with
the
scope
of
where
this
is
at
just
like
implementing
the
apis
and
setting
it
on
the
crs,
it
should
be
pretty
safe
and
nothing
too
dastardly
could
occur.
A
A
Have
a
path
forward,
so
they
just
had
me
just
take
it
and
run
with
it
on
the
task
stuff
and
if
you
need
any
help
or
if
you
need
a
little
bit
of
support
on
just
stories,
to
keep
the
wheels
turning
while
you're
trying
to
flesh
that
out,
then
either
reach
out,
or
I
would
say
just
dip
into
anything.
You
see
in
the
american
side
that
you
think
is
reasonable
and
all
that
so
yeah
go
for
it.
B
B
H
B
B
F
B
Yeah
but
the
reconciler
has
to
fetch
the
cf
org
in
order
to
reconcile
it,
so
they
were
anyway.
They
tried
to
reproduce
it
and
couldn't
and
tried
making
the
thing
busy
tried,
like
you
know,
making
orgs
and
spaces
in
a
tight
loop
and
weren't
able
to
reproduce
it
so
they're
trying
essentially
they're
they're
trying
to
rationalize.
How
do
we
fix
something
we
can't
reproduce?
B
I
couldn't
come
up
with
a
good
justification,
so
you
know
it's
possible
that
if
we
were
to
horizontally
scale
our
manager,
then
you
would
have
multiple
instances
with
multiple
clients,
and
you
could
somehow
reproduce
this,
but-
and
I
don't
know
if
they
tried
that
where,
which
is
why
it
would
be
nice,
they
were
here
to
to
speak
to
this,
but
basically
they
settled
on.
They
came
around
to
likes.
As
far
as
we're
able
to
tell
this
is
a
problem
in
the
test,
not
a
problem
in
the
product
until
we
have
evidence
to
the
contrary,.
F
C
B
F
G
I
mean,
I
think
it's
true,
you
probably
can't
reproduce
it,
but
only
as
long
as
the
web
hooks
remain
like
a
singleton
like.
I
know
the
controllers
need
to
be
singleton
like
I
only
have
one
running,
but
I
don't
think
there's
anything
like
technically
why
the
web
hooks
couldn't
be
be
scaled
out,
but
but
it's
probably
fine
well.
C
C
My
personal
opinion
is
that
kubernetes
is
built
around
the
concept
that
the
state
eventually
reconciles
into
its
final
state,
so
it
can
go
through
many
invalid
intermediate
states,
and
this
is
fine
and
just
rejecting
to
create
a
resource
just
because
a
dependency
is
not.
There
doesn't
seem
to
be
quite
quite
aligned
with
this
concept,
because
that
dependence
may
appear
later
on.
C
B
B
Namespace
you
can
put
the
space
in
is
one
that
was
created
through
the
reconciliation
of
a
cf
work,
so
it
isn't
like
you
could
go,
make
all
the
name
spaces
and
then
make
the
orgs
and
spaces
after
like
we
don't
support
that
right
now,
like
maybe
we
will
in
the
future,
but
right
now,
like
the
only
way
this
works.
Is
you
make
your
words?
You
wait
for
them
to
reconcile,
and
then
you
make
the
spaces
in
the
name
spaces
that
were
created.
So
we.
H
B
I
think
for
me
the
way
we
see
the
product
working
right
now,
if
somebody
makes
a
space
in
a
name
space
that
doesn't
have
an
org
present,
it's
much
more
likely
that
they're
just
trying
to
put
a
space
somewhere,
they
shouldn't
and
it's
never
going
to
reconcile
into
something
positive.
So
that's
the
that's
the
reason
we
were
trying
to
test
it.
D
D
C
C
B
B
B
D
I
was
just
a
thought
that
maybe,
if,
if
you
can,
if
you
can
figure
out,
what's
the
cfo
associated
with
the
namespace,
you
cannot
create
anything
without
a
namespace
in
kubernetes
right.
So
maybe
we
just
remove
that
org
reference,
explicit
org
reference
and
every
time
we
need
it,
we'd
figure
it
out
from
the
namespace,
because
the
namespace
is
a
field
you
can't
do
without.
B
H
G
B
B
D
A
Interesting,
certainly,
some
information
to
chew
on
I'm
gonna
do
a
little
time
check.
We
are
scheduled
on
this
meeting
for
a
little
bit
under
one
more
minute,
so
we
should
probably
think
about
wrapping
it
up
unless
something
is
terribly
pressing,
so
maybe
offer
your
final
thoughts
on
at
least
for
now
on
this,
and
we
can
always
continue
it
next
week.
I
So
you
don't
need
a
hotel
room
for
sunday
night,
most
importantly,
but
you
know
for
those
of
you
that
are
going
to
come.
I
hope
lots
of
you
go
ahead.
You
know
those
those
flights
so
yeah
tuesday,
then
we'll
have
a
booth
on
the
floor
of
kubecon
that
I'd
love
to
get
a
good
number
of
kariffy
and
paquetto
floats
at
on
that
wednesday,
thursday
friday
and
we'll
be
making
a
public
announcement
to
the
wider
community,
probably
this
thursday.