►
Description
[BR] Default Roles
Difficult to test
Might be more expensive than at first glance
Perm project retirement: https://lists.cloudfoundry.org/g/cf-dev/topic/proposal_to_retire_the_perm/74842395?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,74842395
This should still be easier than Perm since we don’t have to deal with a then 7 year old metaprogrammed codebase, but may still be more complicated than it seems
Is manual testing adequate? What is the cost of automated testing?
Pick glaring omission role and fill out slowly.
[GC] Branch protection PR
[RI] Why can’t Korifi default to list all Buildpacks available from Paketo? (Reference conversation)
At least DotNet Core, Python, and PHP.
Expose list of buildpacks in values file?
Simple configuration as list value in the Helm chart.
Experiment to see how much bloat from adding extra buildpacks.
[RI] v0.8.0/v0.8.1 is out. Could we go through the release notes and see what the implications are of each of those items?
UPSI service label proposal UPSI Service Label Enhancements has more info on that item
A
B
It'd
be
tricky
to
test
in
a
way
like
you
have
to
yeah.
We
I
don't
know
if
we
wanna
how,
if
and
how
we
want
to
test
them.
Maybe
just
manually
I,
don't
know
but
yeah
we've.
We
need
a
some
kind
of
process
to
double
check
them
as
we
yeah,
because
it's
easy
to
get
things
wrong
or
to
leave
things
out
or
to
accidentally
give
extra
privileges
or
stuff
like
that.
Yeah.
C
A
I
think
that's
a
really
good
point.
I
think
the
we
should
definitely
focus
on
like
making
the
the
stories
very
small
to
say,
restrict
like
one
role
and
like
evaluate
the
permissions
for
each
roll,
rather
than
just
doing
everything
in
a
broad
sweeping
pass,
because
I'm
sure
there
will
be
issues
with
the
existing
MNS
and
whatnot
since
they
kind
of
use.
Whatever
role
has
the
permissions
they
need,
but
yeah.
That's
a
good
point.
A
D
I
I
think
I
think
it's
a
good
idea.
I
think
it's
going
to
be
more
expensive
than
we
might
think
it
is
so
like
I
think.
Maybe
we
should
Target
like
pick
some
of
the
roles
that
we
think
are
most
valuable
and
do
those
do
those
first
because,
like
like
Giuseppe,
is
saying:
if
we
test
this
adequately,
it's
gonna
we're
gonna,
find
a
lot
of
things
and
it's
gonna
be
like
a
I
guess.
D
This
is
reminding
me
basically
of
when
we
try
to
re
rewrite
the
role:
implementation
in
Cloud
controller,
to
use
the
the
perm
service,
and
while
doing
that,
we
found
the
lack
of
existing
tests
and
definition
of
what
these
roles
should
do.
I
actually
made
it
have
a
huge
like
exploratory
burden
on
each
endpoint
and
each
role
we
were
touching
so
like
I
I
think
we
won't
hit
that
to
the
same
extent,
because
it's
like
a
smaller
and
less
Legacy
code
base,
but
we're
still
gonna
like
bump
into
to
things
like
that.
A
B
Yes,
we
discussed
this
I
think
last
time
we
were
thinking
about,
so
we
basically
what
happened
is
we
we
used
to
have
some
Branch
protection
rules
which
were
just
manually
set
on
our
branches
from
the
from
the
GitHub
UI,
and
then
the
automation
that
we
get
the
repository
automation
that
we
get
via
the
community
repository
also
includes
adding
default
Branch
protection
rules
if
you
just
slip
flip
a
flag
to
true
so
you're
like
okay.
Let's
do
that?
B
I
just
wanted
to
raise
this
with
everyone
in
case
anyone
had
opinions,
slash
memories
of
how
we
use
this
I'm,
pretty
sure
we
we
didn't
have
that
because,
like
leads
are
part
of
the
Bots
group
and
I
never
saw
any
way
to
override
you
know
to
merge
PR's
without
by
skipping.
You
know
by
skipping
checks
or
stuff,
so
I'm
pretty
sure
we
didn't
have
them.
It
doesn't
mean
it's
a
bad
idea
to
put
them
now
to
put
them
in
now.
B
I
just
wanted
to
hear
from
everyone
about
this,
because
yeah
I'm
not
sure
we
should
do
it
or
not.
It's
probably
fine,
either
way.
Once
we
agree
on
that,
I
think.
Another
point
they
raised
is
the
syntax
we
used.
They
suggest
the
syntax,
but
given
their
syntax
Maps
one
to
one
to
the
GitHub
syntax,
because
the
tool
just
talks
to
is
just
making
requests
to
GitHub.
They
adopted
pretty
much
the
same
syntax.
B
So
the
github.json
and
reading
the
GitHub
docs
I
saw
that
the
field
the
day
document
is
actually
deprecated.
I
used
the
new
fields
that
GitHub
recommends,
but
now
I've
been
told
on
this
side
that
the
syntax
is
not
correct,
but
the
checks
on
the
pr
are
passing
so
I
don't
know.
I
might
have
to
basically
rework
the
API
using
the
old,
separate
the
syntax.
If
it's
the
only
one
that
they
support
on
the
on
the
automation
tool,
this
it's
called
prow
or
something
so
yeah.
B
Basically,
a
couple
of
things
to
solve
on
that
PR
keep
an
eye
on
Etsy.
If
there
is
any
thing
you
want
to
add
otherwise
yeah
just
I
guess
it
will
get
in
eventually
and
we'll
get
the
best
of
both
worlds.
We'll
get
the
branch
protection
rules
we
want,
but
applied
by
the
community
automation
instead
of
being
applied
manually
by
ourselves.
A
B
A
C
E
Yeah
the
background
is
this
conversation
that
was
started
by
Silvan.
So
Silvan
is
one
of
the
contract
writers
for
the
foundation
and
he
was
trying
to
push
a
python
app,
which
unfortunately
did
not
push
on
the
first
strike
and
then
a
little
bit
of
Investigation
and
thank
you
Tim
for
helping
narrow
down
the
issue.
We
found
out
that
by
default
query
fee
does
not
have
python
listed
as
a
build
pack
inside
the
cluster
Builder
I.
Don't
see
a
reason
why
that
should
be.
E
B
Here,
I
guess
the
only
trade-off
would
be
size
of
the
Builder
image
Maybe
time
necessary
to
build
that
Builder
image.
When
you
install
korify,
maybe
it
will
take
a
little
bit
longer,
but
also
yeah,
I
guess
the
list
we
have
now
is
kind
of
arbitrary
there's.
No
reason
python
should
be
out.
It's
probably
the
second
most
used
language
in
the
world
or
something.
B
D
D
D
B
D
F
B
B
Somewhere
in
the
hand,
charts
right
because
then
yeah
the
Hem
chart
actually
creates
the
default
Builder.
If
you
want
to,
but
that's
it
like,
we
don't
really
in
the
instructions.
We
say.
If
you
want,
we
create
a
builder
for
you.
Otherwise
we
we
want
yeah.
So
we
have
Java
node
Ruby
proc
file
go
not
too
far
right,
we're
missing
dot
net.
Does
it
make
sense
to
have.net,
given
we
don't,
we've
never
tested
on
Windows.
D
G
B
C
C
B
B
B
Because
there
is
already
I
think
a
some
flag
about
you
know,
create
default,
Builder
or
something
which
people
can
turn
off
if
they
want
to
provide
their
own
I.
Think
we
document
all
of
that,
but
like
at
the
same
time
like
one
thing
is:
oh
I
want
to
make
like
a
very
sophisticated,
build
pack
with
groups
and
stuff.
Then
yeah
you
can
provide
your
own,
but
if
they
just
want
python
or
I,
don't
know
Scala
or
whatever.
We
should
make
it
easier.
Like.
C
B
B
C
B
B
D
B
A
B
D
D
B
D
F
E
E
Let's
start
at
the
beginning,
so
the
first
one
says
something
makes
app
pushes
much
faster
and
so
something
being
a
single
kpac
dot
image
per
app.
So
could
you
give
some
details
about
what
the
exact
changes
and
is
it
just
the
build
casing
feature
of
kpac
that
is
causing
this
change
in?
So
is
this
like
a
k-pak
thing
that
was
recently
released,
or
are
we
just
taking
advantage
of
it?
E
B
It's
it's
just
a
feature
of
Kpop
that
we
were
not
leveraging
before,
because
okay
k-pak,
when
used
Standalone,
is
supposed
to
be
used
with
this
image
object.
Well,
like
you,
create
an
image
and
you
assign
sources
to
it.
Basically,
and
when
you
push
new
sources,
the
image,
notices
and
rebuilds
right
yeah,
but
in
CF
we
don't
really
use
it
in
Korea.
We
don't
really
use
it
that
way,
of
course,
because
we
control
the
the
source
push.
B
Now
we
figured
a
way
to
have
one
long-lived
kpac
image
per
app,
which
means
when
we
do
subsequent
pushes
of
the
same
amp.
We
use
the
same
kpac
dot
image,
and
this
results
in
this
cache
volume
being
reused
across
these
pushes
and
what
we
noticed,
experimentally,
like
just
playing
locally.
Is
that
or
if
you
push
like,
if
you
pushing
up
twice,
the
second
push
is
almost
instant
like
we're
talking
about
and
full
of
seconds.
C
B
C
C
B
D
E
C
B
E
B
And
then
you're
going
to
push
you
can
you
can
use
it
in
Korea?
We
still
don't
have
that,
but
at
least
we
wanted
people
to
be
able
to
say
of
the
build
packs
that
you
have
in
your
list,
which
is
immutable
at
the
moment.
Can
I
just
use
one
because
that
that
will
save
me
going
through
the
detection
phase
every
time
because,
like
basically,
the
app
sources
go
through
the
detection
for
every
build
pack
until
one
matches,
and
that
takes
time
and
if
you
already
know
which
build
pack,
you
want.
B
There's
no
reason
to
go
through
that.
Every
time
you
push
so
now
we
allow
people
to
specify
the
build
packs
that
they
want
either
in
the
Manifest
or
with
Dash
B
in
the
CLI,
and
basically
corifi
will
create
a
temporary
cluster
builder
for
kpac.
That
only
contains
the
build
pack
that
you
selected
and
that
will
make
the
detection
phase
instantaneous.
Basically
because.
C
B
B
B
C
B
For
user,
provided
Services
is
a
bit
of
a
tricky
one.
If
I
understand
it
correctly.
In
CF
for
VMS
managed
services
have
labels
right,
which
are
used
by
Frameworks,
for
example,
to
detect
which
binding
they
want
to
use
when
starting
up
and
user
provided.
Services
usually
don't
have
labels
like
they
only
have
one
label
which
is
like
user
Dash
provided.
B
But
this
me
this
means
that
you
cannot
use
a
user
provider
service
to
pretend
to
be
a
managed
service.
Your
user
provider
service
will
always
be
clearly
labeled,
as
user
provided,
but
given
corifi
still
doesn't
support
managed
Services.
We
want
to
allow
users
to
pretend
to
have
managed
Services
by
creating
user
provided
Services
which
look
like
managed
services,
so
at
least
they
can
push
these
apps
using
these
Frameworks
that
rely
on
these
labels
right.
So
this
is
this
kind.
This
goes
beyond
what
cf4
VMS
does.
B
In
fact,
we
allow
people
more
flexibility,
because
at
the
moment
we
don't
have
managed
services,
and
this
is
the
only
workaround
they
have
if
they
want
to
use
these
Frameworks.
The
only
option
they
have
is
the
user
provided
Services.
We
want
to
be
for
them
to
be,
at
least
able
to.
You
know,
extract
these
Frameworks
into
using
their
bindings,
even
though
they
were
not
created
with
managed
services,
but
they
were
created
with
manually
created
user
provided
service.
B
B
B
Exactly
we
just
implemented
the
same
endpoint
as
CF
implements,
we
implemented
it
and
we
we
did
it
by
leveraging
kubernetes
capabilities
which
are
native.
So
now
you,
when
you
do
when
you
do
a
push
or
restart
or
restage,
with
this
the
strategy
rolling,
it
will
work.
The
only
problem
is
I.
Don't
remember
exactly
why,
but
we
couldn't
make
existing
stateful
sets
like
existing
app.
Push-Ups
immediately
supports
this
strategy
right.
B
They
need
to
be
at
least
three
stage,
I
think
once
or
restarted
I
think
at
least
once
and
like
so
we
we
pondered
what
do
we
do
like
if
someone
tries
to
use
the
rolling
strategy
for
an
app
that
hasn't
been
restarted
yet
like?
How
do
what
do
we
do?
Do
we
do
an
unrolling
restart
without
telling
the
user?
Do
we
fail
I?
Think
in
the
end,
we
settled
with
I
think
a
failure.
So
if
you
try
to
I,
think
use
the
rolling
strategy
on
an
app
that
hasn't
been
restarted.
C
B
B
Apps
are
still
around
and
as
part
of
this,
we
are
now
annotating
the
the
objects
that
corifi
creates
with
a
with
a
version
of
corifi
that
created
them.
This
allows
us
to
apply
even
in
the
future,
we'll
we'll
be
able
to
apply
all
sorts
of
conditional
logic
based
on
you
know
the
qualify
version,
because
we
will
know
exactly
which,
which
version
of
corifi
was
used
to
create
slash,
update
that
resource
for
the
last
time
right
so
for
apps
when
they
get
restarted,
they
get
the
new
label
and
we're
like
okay.
B
Now
we
know
this
is
this
the
supports
rolling
we
can.
We
can
make
it
roll,
but
I
did
so
here
in
the
in
the
notes.
I
said:
yeah
I
explained
this
that
you
have
to
restart
first,
but
technically
you
shouldn't
need
to
read
the
release.
Notes.
If
you
try
to
do
a
CF
start
scrolling,
you
should
restart
rolling.
You
should
get
a
good
enough
error
message,
I
guess,
which
tells
you
to
restart.
First.
E
B
B
E
B
Right,
but
you
you
still
do
the
request
for
a
specific
org.
You
just
get
the
same
response,
regardless
of
the
org
I
believe
what
else
jobs
is
I,
guess
one
of
the
biggest
things
that
we
implemented.
It's
a
way
to
tell
any
API
client
really
to
keep
any
any
client
up
up
to
date
with
some
long
running
operations.
So
this
is
how
the
CF
API
does
async
stuff.
When
you
perform
an
operation
that
is
supposed
to
take
long,
the
CF
API
doesn't
block.
B
Instead,
it
redirects
you
to
this
job
resource,
which
you
can
pull
to
know
what's
going
on
basically
and
this
the
operations
that
support
this
flow
are
mostly
deletions,
plus
the
Manifest
application
operation
also
has
this
and
inquiry
implementing.
This
was
a
bit
tricky
because
we
we
didn't
implement
this,
like
let's
say
in
the
in
the
traditional
proper
way,
and
instead
we
kind
of
took
a
shortcut
which
means
we
can
only
support
the
jobs
for
deletions
at
the
moment,
so
for
manifest
application.
B
When
you
apply
manifest,
it
will
still
return
immediately,
even
though
the
Manifest
application
hasn't
finished,
but
for
deletions
previously,
we
used
to
just
return
immediately.
Now
we
don't
now,
we
we
redirect
to
a
job
that
will
be
marked,
as
you
know,
in
progress
until
the
deletion
is
actually
finished,
which
means
now,
if
you
delete
an
org,
for
example,
the
cfcli
which
paused
these
jobs
will
wait
until
the
org
is
actually
gone
while
until
you
know
till
now,
we've
just
returned
immediately.
B
C
B
B
We
had
a
hard
coded
I
think
time
out
until
we
marked
it
as
failed
or
something
now
you
can
configure
that
timeout
so
that
if
your
custom
build
pack
is
particularly
slow
to
come
up,
you
can
bump
that
time
out.
I
guess:
okay,
staging
requirements
build
cache
MB!
You
can
configure
the
cache
the
the
size
of
the
build
cache.
B
This
is
because
I
think
we
had
issues
where,
like
some
apps
required,
a
bigger
cash,
because
you
know,
for
example,
Java
apps,
usually
so
you
can
configure
the
the
size
of
the
bill
cache
and
and
we
will
create
the
cache
of
that
size.
You
can
also
change
this
for
existing,
like
for
apps
that
you've
already
pushed
once
and
we
will
detect
it
and
recreate
the
cache
volume.
B
B
B
C
B
Had
lots
of
back
and
forth
about
how
we
how
we
should
deliver
it
like?
Should
it
be
a
script?
Should
it
be
a
binary?
Should
it
be
a
Docker
image?
Whatever
all
of
these
have
pros
and
cons,
and
we
haven't
really
discussed
it
in
the
wild,
but
it's
something
that
I
guess
we
should
reconsider,
because
in
the
end
like
before,
to
release
zero,
eight
I
asked
Yogi
to
take
care
of
it
and
usually
what
we
do
is
we.
B
We
pre-release
try
the
turbo
locally
unkind
and
if
the
installation
works,
it
means
the
install
instructions
are
correct
and
then
we
released
and
even
Yogi
got
stuck
because
he
made
a
mistake
because,
like
I,
don't
know,
he
misread
some
instructions.
So
this
is
to
say
that
even
people
who've
been
on
the
team.
B
Since
you
know
literally
day
one,
they
can
still
sometimes
make
mistakes
following
the
instructions,
because
maybe
you
skip
a
step
and
accidentally
or
you
forget
something
you
know,
even
if
the
instructions
are
not
wrong
per
se,
it's
clearly
not
an
ideal
experience
so
which
we
should
think
about
something.
In
my
opinion,
I,
don't
know
what
exactly,
but
something
for
kind,
because,
like
I,
think
I'm
in
a
universal
installer
is
not
an
option.
In
my
opinion,
but
like
giving
kind,
is
a
much
more
controlled
environment
I
think
should
be
able
to
ship
something.
B
We
already
have
a
script,
the
infamous
the
pre-owned
kind,
but
I'm
nervous
about
stripping
shell
script,
because
literally,
everyone
is
running
a
different
version
of
the
shell
and
like
Max
ship,
very,
very
old
bash.
For
example,
we
use
We
Run,
The
zsh,
and
our
machines
like
trying
to
and
like
Max
have
different
version
of
the
binaries.
They
have
the
BSD
versions.
Other
people
run
the
new
version
of
the
binaries,
like
it's
an
extremely
volatile,
extremely
uneven
kind
of
environment.
B
Trying
to
support
like
I
can
see
how,
like
it's
very
hard
to
support
pretty
much.
Everyone
like
people
will
not
be
able
to
install
the
dependencies
or
they
will
have
a
version
of
bash
which
doesn't
support
a
specific
syntax
or
which
is
why
I
was
thinking
of
Alternatives
I.
Couldn't
find
any
that
really
convinced
me,
but
we
should.
We
should
keep
looking
because
the
script
the
script
we
have
now
runs
on
our
machines.
It's
a
very
small
sample
size.
B
It's
like
I,
don't
know
10
people
and
we
still
have
a
bunch
of
IFS,
because
some
people
will
develop
on
Max.
Some
people
develop
on
Linux
and
we
already
have
like
a
few
like
issues
of
incompatibilities
on
a
population
of
like
I.
Don't
know
eight
developers
so
I
cannot
imagine.
I
cannot
imagine
releasing
this
to
the
public.
It's
it's.
G
B
C
B
C
E
B
Have
this
like
I
guess
very
unusual
idea
of
like:
can
we
ship
an
image
that
runs
kinds
inside
so
that
you
just
start
it
and
you
have
a
full
kind
with
corifi
all
in
that
image,
but
that
also
sounds
complicated.
It's
like
Docker
in
Docker
in
Docker
in
Docker.
It's
like
four
layers,
I,
don't
know
if
it
feels
very,
very
complicated,
so
I
honestly,
don't
know
we
should
discuss
and
figure
out.
B
What's
the
best
way
to
go
and
do
something
and
if
we
can't
find
anything
better
than
just
ship
Deploy
on
kinda,
let's
just
ship,
the
plugin
then
see
how
it
goes
at
least,
and
maybe
it's
not
that
bad.
You
know.
Maybe
it
will
already
run
fine
on
99
percent
of
machines
and
we
don't
have
to
worry
really
yeah.
C
G
B
E
B
There's
people
ship
shell
scripts,
so
people
do
do
ships
shell
scripts.
It
is
possible.
Our
R1
is
probably
not
the
most
complicated
shell
script.
You
know
shipped
as
a
public
product,
so
yeah,
it's
it's
feasible,
so
we
should
at
least
try
and
honestly
even
shipping,
like
they're,
probably
with
a
golang
binary,
is
that
we
have
to
build
it
for
all
platforms.
C
B
You
can
you
can
release
a
go
file
as
in
a
as
a
script
and
let
ask
people
to
do
go
run,
but
then
people
have
to
install
go,
which
is
not
something
everyone
has
installed
while
bash
is
or
like
a
shell
is
probably
something
that
people
will
have
again.
Docker
Maybe
there's
a
way
in
Docker
to
access
the
host's
localhost
right.
So
maybe
that's
a
cool
trick
and
then
you
only
have
to
run
docker,
which
is
I.
B
Think
not
a
big
ask
because
like
if
you
want,
if
you're
running
kind,
you're
already
running
Docker,
so
it's
it's
a
dependency
that
is
already
there
and
you
cannot
really
skip
it.
So
maybe
that's
how
we
avoid
all
the
differences.
Maybe
we
can
pull
that
off.
I
don't
know
because
in
the
end
my
reasoning
is,
like
kind
is
going
to
be
on
your
machine.
B
E
B
B
G
B
C
C
B
Everything
via
that,
it's
fine,
we
just
have
to
tell
people.
Please
create
your
cluster
at
your
discretion
like
create
your
kind
cluster,
as
you
want
and
then
make
sure
you've
you
you,
let
I
guess
tell
us
how
to
reach
it.
So
you
have
to
give
us
the
the
address
or
something,
and
then
we
can
talk
to
it.