►
From YouTube: Cloud Foundry for Kubernetes Monthly SIG [Dec 17, 2019]
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
A
Give
her
a
couple
of
seconds
to
push
the
button
so,
okay,
it's
already
on
so
then
welcome
to
this
kind
of
extraordinary
special
interest
group
called.
So
we
said
we
wanted
to
have
one
right
away
before
everybody
signs
off
for
vacations.
Most
people
sign
off
for
vacations
I
actually
like
just
went
through
the
minutes
from
last
time,
which
I
think
again.
Eric
took
the
burden
to
listen
to
the
call,
contribute
and
type
simultaneously,
which
like
still
leaves
me
in
awe.
So
thank
you
very
much
for
keeping
the
the
minutes
there.
So
I
guess.
A
Last
time
we
had
a
me
tree
showing
a
ytt
game.
Oh
then
I
think
afterwards,
bringing
in
the
discussion
on
how
what
we've
seen
there
relates
to
see
of
operator
/
course
and
then
I
think
we
started
the
discussion
around
like
which
quality
is.
Do
we
want
to
see
from
a
cloud
foundry
on
kubernetes
in
terms
of
day
2
operations,
secret
rotation,
update,
et
cetera,
et
cetera
and
then
I
think?
A
B
Sure
so
Ladin
I
and
few
others
met
yesterday
yesterday,
yeah,
thank
you
yeah,
so
I
think
we
there
was
like
a
first
intro
sort
of
deep
dive
into
cube
CF.
Where
is
that
where
it
is
right
now
what's
in
the
pipeline,
one
hour
was
not
enough:
they
were.
We
had
few
discussions
around
how
this
some
of
the
integration
pipeline
could
help
our
teams
and
then
also
there
were
some
open
questions
around.
How
can
we
swap
you
know
Kay
centric
components
with
the
debasht
components
right,
so
that
was
sort
of
the
idea.
B
Like
you
start
with
the
base
keeps
you
is
the
base
and
then
you
can
swap
out
with
it
with
Kasich
eight
centric
components
as
they
are
ready
to
integrate.
So
we
plan
to
have
a
meeting
on
the
January
6th
making
to
you
know
to
sort
of
deep
dive
into
that
specific
part.
Also
I'm
trying
to
see
where
else
was
all
about
meeting
blood
is
that
did
I
summarize
what
we
talked
about
yesterday,
yeah.
B
B
We
had
meetings
with
contributing
teams,
cappy's
and
the
networking
team
and
so
on
and
the
fundamental
need.
What
we
noticed
is
a
local
artifact
I
can
that
I
came
that
they
can
rapidly
iterate
on
locally.
They
wanted
a
very
lightweight
system
because
they
they're
not
ready
yet
for
to
have
a
full-on
cat's
running
or
any
of
the
other
tests,
or
for
that
matter
the
whole
integration
there
they're
not
looking
to
build
a
CI
pipeline
at
this
moment
right
now.
B
They
just
want
to
be
able
to
reiterate
rapidly
and
and
work
directly
with
other
teams
instead
of
using
in
a
whole
integration
pipeline,
like
we
do
today
with
CFD
appointment.
So
that's
the
one
one
thing
that
we
observed
so,
in
other
words
similar
to
Bosch
light,
but
on
cake's
basically-
and
we
also
heard
this-
a
few
teams
have
struggle
with
using
qcf,
mostly
ran
performance
issues.
Maybe
there
was
a
resolve,
but
the
number
of
cap
instances
that
creates.
B
Another
approach
is
that,
like
that's
one
approach,
the
other
approach
that
I
think
I
mentioned
is
that
can
we
create
a
smallest
artifact,
it's
very
minimal
config
for
teams
that
they
can
iterate
on
locally.
So
this
may
not
be
something
that
a
community
someone
who
was
running
safe
deployment
by
doing
Bosch
deploy
today
may
not
be
available
for
them,
but
it's
mostly
for
the
teams,
those
who
they
can
iterate
on
it
again
very
much
like
ash
like
world,
so
those
are
the
those
are
some
ones.
B
Some
of
the
things
that
we
explored
in
the
inception,
I
think
I
think
we
are
working
towards
like.
Is
it
possible
to
create
a
smallest
artifact
and
the
tooling
around
that
for
teams
to
unblock
locally
to
so
that
they
can
iterate
locally?
So
that's
where
we
are
today
and
then
we
want
to
explore.
You
know.
The
second
step
obviously
is
going
to
be
okay.
What
kind
of
reference
five
points
so
we
could
they
can
use
and
what
are
the
integration
pipelines
like
we
do
today
for
CF
deployment,
so
think
about
that
as
phases.
B
C
We
are
looking
for
that
to
in
the
sense
that
local
development,
it's
been
a
focus
for
us
for
some
time
trying
to
make
it
as
painless
as
possible
to
iterate
whether
it's
just
starting
up
from
scratch.
You
know
a
cluster
or
replacing
the
component
that
you're
working
on
right,
iterative,
yeah,
I,
think
I
think
we
have
ways
to
improve
that
I.
Think
most
of
the
developers
working
on
cube,
CF
right
now
use
kind
kind,
locally,
there's
a
quick
way
to
get
a
kids
up
and
running
locally,
and
then
you
deploy
cube
CF
but
I.
C
Think
there's
also
something
to
be
said
about
minimizing
the
cube
CF
that
you're
deploying
locally.
For
example,
you
don't
need
all
the
build
packs
right,
every
time
that
you
deploy
so
maybe
having
some
controls
on
exactly
what
do
you
want
to
be
part
of
this
thing
that
you're
deploying
every
time
so
that
could
be
nice.
C
D
C
C
The
people
can
start
playing
around
with
and
right
after
that,
I
think
a
very
good
focus
would
be
to
replace
the
bars
release
of
ireenie,
with
the
upstream
irony
hump
chart.
So
kubernetes
native
component
I
think
that
would
be
a
good
display
of
the
features
that
I
talked
about
yesterday,
where
you
can
mix
and
match
Bosch
and
non
bar
stuff,
and
you
know
it
could
be
a
success
story
like
if
it's
really
easy
and
again
as
an
Irene
developer.
D
Point
glad
it's
not
a
technical
point,
but
it
is
sort
of
a
procedural
point.
I'm,
not
sure
everyone
knows
that
Susan's
intention
is
to
donate
this
to
the
Fed,
keep
CF
to
the
foundation
that
we've
got
a
timeline
for
this
a
fairly
eyes
and
as
soon
as
we
can
so
then
cube
CF
would
be
governed
by
the
CLA,
etc
and
because
I
get
the
impression
that
people
still
think
of
it
as
a
Sousa,
only
project
and
what
what
work
remains
to
be
done
before
we
can
put
this
in
the
Cloud
Foundry
organization
on
github
I.
C
D
C
D
Okay,
if
we
can
evangelize
that
through
our
teams,
so
that
we
can
make
sure
especially
I,
don't
know
Eric
if
you
can
make
it
known
that
that
is
that's.
That
is
this
the
state
currently
and
that's
the
intention,
because
I
think
that
some
of
the
the
sort
of
lack
of
recognition
of
cube,
C,
F
and
and
of
that
it's
there
for
people
and
that
it's
gonna
be
something
they
can
consume-
comes
from
the
fact
that
it's
sitting
in
the
Sousa
org
right
now
so
just
to
let
everyone
know
that
that's
that's
gonna
be
changed.
D
D
F
F
F
E
F
B
What
you
saw
was
a
combination
of
tools
yeah
last
week,
not
just
ytt
I,
believe
what
you
saw
was
that
all
of
the
k14
tools,
so
he
was
using
ytt
what
if
he
only
does
templating
and
that's
all
it
does,
there's
absolutely
nothing
in
it.
It
has
some
you
can
use
to
sort
of
create
in
templating
language
in
there.
So
as
in
like
hey,
you
know
this
specific
blog.
B
If
this
is
true
at
the
specific
block,
but
that's
still
working
in
the
realm
of
the
template,
what
you
saw
probably
was
cable,
which
is
building
the
docker
images
and
then
I
believe
cap,
which
is
deploying
that
docker
or
that
resource
to
Kate's
cluster.
So
there
are
three
different
tools:
I
think
he
did
a
demo
last
week,
so
ytt
in
itself
is
pure
templating.
It
has
absolutely
no
well
no
recognition
of
what
K
is
like.
B
D
I
think
that's
where
there
are
concerns
about
people
not
using
CF
operator
came
in,
like
the
CF
operator
is
designed
to
do
lifecycle
management
of
Cloud
Foundry.
Well,
it's
designed
to
do
more
than
that
actually,
but
that
is
the
core
purpose
of
it.
And
if
this
logic
is,
you
know
not
being
used
or
if
those
capabilities
aren't
being
used.
Maybe
the
component
teams
are
going
to
be
building
the
logic
into
their
into
their
release.
Tooling,
and
we've
been
down
this
road
of
trying
to
do
it
without
an
operator
and
I.
C
We
talked
about
this,
the
need
for
an
operator
currently,
of
course,
if
the
core
of
Cloud
Foundry
changes
right.
So
if
the
Caffrey
team
changes
the
clock,
controller
itself
and
the
routing
layer
and
etc,
then
you
might
not
need
an
operator
in
the
future
right
that
that
those
components
have
to
change,
to
support
a
Canary's
native
approach,
where
you
don't
have
an
active
operator
to
manage
all
the
configuration
and
certificates
and
so
on
so
and
that
that's
awesome
for
the
future.
I
think
like
after
we
get
rid
of
the
last
boss
component
in
qcf.
C
We've
had
some
experience
with
helm.
Now
we've
had
a
product
being
delivered
with
helm
for,
like
a
couple
of
years
now
and
I,
don't
think
we've
seen
many
problems.
It
also
acts
as
a
delivery.
Channel
right,
helm
repositories
take
software
to
the
customer,
and
it's
also
wildly
supported
by
the
community
I've
seen
a
bit
of.
C
D
Yeah
well,
I
think
I
mean
I.
Think
we
thought
that
there
there
certainly
some
weaknesses
in
helm
that
we've
we've
acknowledged
and
it
did
you
know
it
did
not
do
and
at
least
initially
what
what
everything
that
we
hoped
that
it
would
have.
We
had
to
do
some
some
fancy
things
to
make
it
work
for
our
customers.
The
upgrade
path
was,
was
difficult
and
required
manual
intervention.
A
C
D
D
And
I
think,
but
but
the
point
is
this
is
why
we
built
an
operator
just
because
we've
fought
with
helm
and
have
a
adding
things
to
CF,
to
manage
lifecycle,
certain
components
to
generate
certs.
To
do
these
things
that
oh,
we
forgot,
we
have
to
do
that
with
with
cloud
foundry.
Oh
we
forgot.
We
have
to
do
that
with
cloud
foundry
the,
and
we
got
to
a
point
and
the
reason
we
started
these
conversations
with
IBM
and
I
say
P
was
was
like
okay,
we
do
need
an
operator.
D
We
do
need
something
to
handle,
manage
the
lifecycle
in
place,
because
we
don't
because
we
don't
have
boss
and
I
just
want
that
knowledge
to
be
shared
with
all
of
the
CF
component
teams
that
are
going
to
start
building
kubernetes
native
stuff
I
mean
in
a
truly
kubernetes
native
component.
This
stuff
won't
be
as
necessary,
but
to
understand
what
is
there
in
the
operator
to
to
help
them
get
what
they
have
right
now
into
a
containerized
per.
G
Head,
let
me
add
just
one
comment
on:
why
held
against
why
we
should
try
to
avoid
just
using
cube.
Ctl
apply
all
the
time,
at
least
from
IBM
and
the
experience
we
have
now
with
cube
CF.
It
allows
you
to
have
higher
vision
on
the
changes
you
have
been
applying
since
you
deploy
cloud
foundry
troll
cube
CF.
If
you
rely
only
on
cube,
CTL
apply,
you
don't
have
actually
a
clue
on.
What
have
you
been
changing
your
co-founder
instance
exactly.
A
H
I
would
I
would
like
to
like
put
on
a
on
a
string
here
that
came
through
in
and
one
of
the
things
that
that
Troy
said,
like
you
mentioned
that
the
operator
you
have
been
building
for
like
the
last
year
or
so
was
specifically
born
with
the
thought
in
mind
that
he
would
be
consuming
motion
pieces.
But
you
would
not
have
bought
right
and
I
agree
in
order
to
achieve
that
and
to
deploy
motion
eases
alternatives.
You
obviously
need
some
component
doing
office
job
and
that's
like
the
operators.
H
I
think
what
we're
seeing
like
currently
is
more
and
more
active
portion
like
real
movement
within
the
runtime
teams,
move
to
like
to
move
away
from
exclusively
packaging,
their
things
as
Bosch
releases
and
I.
Think,
like
my
my
feeling
now
from
a
bit
more
of
like
an
observing
position,
is
that
this
leads
to
now.
The
conflict
of
like
one
side
of
people
is
still
saying
like
hey.
H
We
need
this
operator
because,
like
we
started
from
here-
and
this
is
what
we
like
learning
and
discovering
on
the
way-
and
this
is
how
we
do
it
currently,
whereas
like
the
other
side
of
of
people
like,
has
actually
moved
away
from
the
starting
premise
of
why
an
operator
in
this
specific
way
you
build.
It,
is
and
and
was
necessary.
D
Yeah
no
and
I
get
that
and
we
are
looking
for
an
end
state
where
we
build
cloud
native,
come
the
kubernetes
native
components
and
we
don't
need
Bosch
but
getting
there,
especially
for
those
of
us
I
be
m
and
Sousa
that
already
have
a
containerized
distribution.
I
already
have
a
kubernetes
distro
to
get
there.
D
While
we
have
a
world
of
Bosch
releases
and
then
at
some
point,
presumably
pivotal
cutting
over
to
to
kubernetes,
enabled
Cloud
Foundry
we're
going
to
have
to
maintain
those
Bosch
releases
up
to
a
certain
point
and
as
we
introduce
the
new,
the
new
release
process.
So
these
are
going
to
overlap
for
some
time
until
that
until
the
kubernetes
native
components
are
ready,
and
so
we
have
to
be
able
to
swap
them
in
and
out,
and
so,
if
then,
new
and
and
yes
I
agree.
D
I
But
I
think
also
the
operators
not
entirely
about
just
being
able
to
consume
Bosch
releases,
there's
aspects
of
what
it
does
I
mean
for
the
complex
multi
micro
service
environment.
Where,
especially
where
some
aspect
of
statefulness
exists.
You
know
the
data
associated
with
the
CCTV
and
such
there
is
the
way
to
do
it
on
kubernetes
is
the
operator
they
came
into
existence
for
a
reason
for
that
kind
of
particular
reason.
H
H
This
I
mean
last
week
we
have
the
example
of
FK
native
I
mean
further.
There
is
a
Kennedy
for
ATAR.
If
you
want
that,
you
can
also
just
use
cube,
CT
and
offline.
It's
ok
native!
It's
not
that
hard
and
like
right
now,
you're
you're
right!
There
is
control
the
database,
but
do
we
still
need
that
in
a
possible
future?
So
you.
I
E
I
Essentially,
90%
yes,
I
was
agreeing,
but
the
stateful
stuff
still
needs
an
operator.
Now
some
were
getting
rid
of
that
operator.
Indeed
from
anything
by
throwing
their
statefulness
right
down
to
the
kubernetes
level.
I
don't
know
that
that
would
actually
I
doubt.
Actually
that
would
scale
in
a
Cloud
Foundry
sense,
but
it
might
for
some
small
pieces.
So,
yes,
the
operator
has
more
the
there's
currently
more
than
it's
necessary
in
the
operator.
If
you
were
to
remove
the
stateless
purely
stateless
pieces,
they
could
become
independent,
but
you'll
still
have
an
operator.
I
So
now,
then,
you
can
argue
about
well,
if
you're
always
going
to
have
it,
what
you
want
to
architect
it
as
a
bigger
chunk
or
separate
off
the
pieces,
but
they
have
to
be
managed
together
anyway,
which
means
you're
you're,
removing
the
management
somewhere
else.
That's
a
different
piece,
but
the
current
architecture
that
we
have
in
cloud
foundry
does
not
allow
for
operation
without
at
least
one
stateful
set,
and
thus
at
least
one
Operator,
and
then
we
can
just
argue
about
how
big
or
small
you
want
to
make
the
surface
around
it
and.
H
C
C
E
C
J
For
me,
there
is
still
a
question
mark
on
how
do
we
integrate
all
those
components
like
how
do
we
do
secret
management
and
certificates?
This
is
a
very
complex
side
of
deploying
Cloud
Foundry
is
to
manage
all
those
certificates
and
connect
the
right
dots
right.
It's
not
just
about
deploying
oh
right,
I,
deploy
those
stateless
staff
and
those
stateful
stuff,
and
then
they
magically
work.
Yeah.
F
C
D
C
I
Well,
I
mean
I,
think
you
know
the
the
point
we're
just
trying
to
make
is.
If
we
can
work
in
concert
together
to
move
things
faster
and
yeah,
there
might
be
an
iterative
approach,
and
certainly
we
can
argue
about
the
scope
of
the
operator
or
even
the
need
of
it.
But
if
we
I
like
to
evolve
idea
what
we're
looking
at
with
what
everyone's
working
on
around
the
operators
already
I'm
sort
of
a
major
v2
architecture
using
some
of
the
newer
kubernetes
stuff,
we
got
to
keep
watching.
I
You
know,
as
kubernetes
itself
evolves
and
can
take
advantage
of
pieces
that
that
can
happen,
but
I'm
I'm,
more
worried
that
oh
there's,
like
you
know,
we
first
principles.
That's
always
nice
to
be
able
to
look
at
things
and
from
the
first
principles,
but
that
it's
maybe
not
being
done
with
realizing.
Okay.
Well,
there's
an
operator
here
or
there's
the
this
is
that's
like
a
year-long
rewrite,
rather
than
I
heard
an
assumption
of
okay.
I
Meanwhile,
we
as
we
did
here
on
just
before
on
the
the
AMA
there
are
still
like
from
s
AP
and
other
these
concerns
where
it's
like.
You
know,
Cloud
Foundry,
who
needs
that
we
already
have
kubernetes
right.
The
the
common
misconception
of
of
an
either/or
opinion
is
still
the
unfortunate
prevailing
one,
and
that's
that's
the
thing
that
I
most
want
to
knock
down
is
have
this
in
front
of
people?
Has
the
de
facto
way
to
do
applications
on
top
of
Cloud
Foundry.
B
So
I
think
I
mentioned
that
the
right
now,
the
teams
that
where
they
are
in
their
journey,
our
goal
is
to
iterate
rapidly
local
environment.
So
that's
why
we
are
focused
on.
We
asked
around
what
sort
of
integration
of
we're
looking
at
for
all
of
the
components
together.
They
are
not
there
yet
so
they're
so
working
towards
individual
components,
trying
to
get
things
working,
maybe
one
or
two
dependencies.
B
So
what
we're
looking
to
do
is?
Can
we
come
up
with
a
very
minimal
the
smallest
artifact
that
can
unblock
them,
and
that
doesn't
mean
that
that's
the
final
state,
that's
just
to
get
them
unblocked,
get
working
on
it
without
any
CI
pipelines
and
then
once
they
are
ready,
where
they
can
start
integrating
other
components.
So,
for
example,
Cappy
only
needs
UA
and
that's
all
they're
focused
on
right
and
now
looking
at
our
can
get
networking
may
need
Cappy.
B
So
when
we
start
seeing
where
there
are
a
lot
of
dependencies
increase,
then
we
can
start
thinking
about
what
kind
of
pipelines
do
we
need,
what
sort
of
artifact
doing
the
rewrite
their
artifact?
Do
we
use
cube,
see
if
that's
what
I
think
the
composition
will
make
more
sense,
because
then
we're
looking
at
a
full
integration
from
both
the
teams
and
then
the
the
tail
end
of
that
which
is
a
which
is
a
CF
sort
of
a
say
of
deployment
integration
that
we
have
today.
B
H
B
So
I
think
the
goal
right
now
is
to
be
iterated
within
the
next
month.
So
I
want
to
be
very
careful
when
I
give
timelines,
but,
like
I
said
we
want
to
ship
something
that
they
could
use,
and
this
is
just
the
target
right
now
is
just
a
contributing
teams,
and
not
necessarily
for
someone
who
wants
a
player.
I
would
see
if
in
the
open
market
so
so
like
to
build
tooling
around
that.
H
So
maybe
something
for
every
like
what
is
your
idea
on
when
and
how
will
teams
be
in
a
state
where
they
actually
try
to
care
about
dependencies
and
of
their
own
components?
Yes,
like
an
isolated
one
again
like
I'm,
not
trying
to
like
pin
you
down
on
an
exact
date
here,
I
just
wanted
to
get
roughly
to
a
common
understanding
of
what
well.
D
C
F
That's
for
exchanging
config
right,
that's
one
step
further,
like
cubes
EF
can
already
deploy
arbitrary
emulator
Q
Q
Benitez,
it's
just
when
you
want
the
data.
When
you
want
the
certificates
and
the
passwords
and
the
IP
addresses
and
most
names
from
the
post
deployment
manifests,
then
you
need
the
quarks
links,
but
if
you
don't
need
any
configuration,
you're
doing
it
by
hand
for
your
dev
teams,
you
don't
need
anything.
No,
it's
just
an
generated
by
basil.
D
C
C
D
I'm
just
interested
in
making
life
easier
for
size
team,
because
we've
gotten.
That
was
that's
kind
of.
Why
I'm
into
this
call
and
like
I,
see
this
duplication
of
effort
and
I
want
to
make
sure.
We
don't
do
that
and
like
that,
we
can
help
in
any
way
we
can
in
relief
in
reducing
the
overhead,
not
only
so
the
the
component
teams
but
precise
team
just
by
using
what
we
built
I.
G
D
J
Maybe
sorry
I
was
not
in
the
last
call
and
I
didn't
see
the
recording
for
me.
I
I'm,
still
lacking
understanding
where,
in
which
level
white
tea
renders
those
templates
and
what
it
is
rendering
and
how
we
would
integrate
with
other
components
like
right,
you
got
copy
with
your
white
adhere
injury,
and
then
you
got
the
database
us.
Our
database
is
not
a
good
example.
J
A
C
C
A
C
D
B
I
think
surly
we
talked
to
yesterday
about
this
and
I
think
the
first
so
second,
meaning
that
we
want
deep
divers
I,
think
we
scheduled
for
January
6th
I
think
these
could
be
two
approaches
that
we
can
take.
They
don't
have
to
you.
Don't
have
to
be
mutually
mutually
exclusive
right,
so
the
cube
see
if
it
speaks
about
a
whole
foundation
does
as
a
whole
CF
work.
And
then
there
are
some
basic
needs
right
now
that
we
need
to
meet.
B
So
it's
just
about
size
and
complexity
and
how
fast
they
can
iterate,
but
I
think
I.
Think
the
next
steps
for
me
sticks
just
to
sort
of
work
with
you
all
to
see
what
how
maybe
you
use
cube
CF
at
the
tail
end
of
the
integration,
perhaps
and
still
have
a
very
small
artifact,
that
the
teams
could
still
use
make.
B
Is
you
know
easier
for
them
to
integrate,
but
yeah
I
I
definitely
think
we
should
just
like
keep
exploring
this
part,
because
I
think
I'm
I'm
concerned
about
using
bash
releases
because
of
the
complexity
as
for
debugging,
especially
now
they
have
to
also
understand
how
CF
operator
works
up
there.
Things
do
fail.
We
have
seen.
We
have
noticed
that
they're
trying
to
get
things
working
they're
the
teams
are
challenges
so
so
yeah.
So
all
those
things
cumulatively
add
complexity
to
to
the
to
the
integration
work.
I
I
I
I
B
Think
that's
a
good
point,
but
I
also
think
this
is
a
good
time
for
us
to
think
about
those
project.
Level
concerns
right,
so
search
rotation
is
that
something
kids
can
do
for
us.
Are
there
existing
solutions
that
we
could
use,
then,
rather
than
be
building
it
on
top
of
it?
So
I
think
I'm
not
saying
that
those
are
the
concerns
we
should
ignore,
but
I
also
feel
that
there
are
those
in
the
case
will
they
do
expose
or
what
I
call
solutions
that
already
exist
so
cube.
B
Cf
may
hide
all
of
that
complexity,
but
it
is
something
that
we
want
to
continue
doing
likewise.
Efra,
there
are
little
ways
we
can
actually
reuse
some
of
the
existing
best
practices.
I've
keep
Cades
offers
in
the
market.
I
think
we
talked
about
if
operator
and
stateful
sets
in
the
beginning,
so
but
yeah
I
think
we
are
not
there.
At
least
our
team
is
thinking
about
that
as
a
face-to
in
different
phases.
D
I
Indeed,
it
does
I
mean
just
and
and
I
think
that's
what
we're
saying
is
that
in
the
iterative
approach,
it's
fair
to
say,
we
should
really
reconsider
what
needs
to
be
native,
as
well
as,
for
example,
bringing
in
sto
to
replace
a
bunch
of
the
internal
plumbing
could
make
things
easier
as
well,
but
then
we're
we're
not
looking
at
a
small
revamp.
It
is
one
that
would
probably
be
awesome
in
the
end,
but
just
it's
not
a
small
bit
work
I.
E
C
E
Mean
I
know
like
the
the
networking
team
is,
you
know
they
they've
already
been
packaging,
sto
components
and
a
new
component
that
connects
Cloud
Controller
data
to
that
for
ingress,
routing
I,
believe
they're
looking
at
ways
to
take
advantage
of
this.
Do
sidecar
functionality
to
handle
some
of
the
security
concerns
between
components,
if
not
between
applications
and
routing
so
I
mean.
Maybe
that's
another
interesting
test
case
for
qcf
is:
could
that
functionality
and
those
component
changes
get
integrated
smoothly
into
that
system.
Yeah.
I
And
I
don't
want
to
like
it's
a
good
discussion.
I
don't
want
to
derail
it,
but
noting
we
only
have
a
few
minutes
left
in
this
is
when
it
comes
to
the
SEO
stuff
and
which
we're
very
interested
in
working
on
is
when
we're
going
to
hit
the
eventual
trade
offs
of
oh
we're
gonna
gain
this
functionality
or
make
this
easier.
C
E
G
G
C
Yeah
SEF
was
not
as
flexible
as
cube.
Zfs
cube,
CF
has
a
bunch
of
integration
points
plus
it
allows
you
to
write,
write,
helm
by
hand
if
he
wanted
to
write
templates
by
hand.
Sef
did
not
allow
you
to
do
that
at
least
at
that
stage
it
didn't
everything
was
generated,
so
you
had
to
around
some
stuff
in.
J
F
Well,
I
think
the
point
is
that
you
will
have
the
logic
somewhere
and
it
doesn't
have
to
be
in
our
current
operator,
but
it
will
be
in
another
operator
or
in
communities
and
the
future
of
the
next
version,
or
in
Capek
or
somewhere
right,
so
yeah
I
mean
I.
Don't
think
we
are
unhappy
if
the
operator
that
we
currently
have,
which
consists
of
like
I,
don't
know
how
many
controllers
more
than
10
controllers.
Well,
if
that
gets
smaller,
and
we
don't
need
it
anymore,
great.
D
F
D
F
No
I'm
not
sure
if
this
is
if
these
features
are
useful
for
the
broader
community,
we
try.
We
would
keep
trying
when
we
have
to
release
out,
but
I
don't
want
to
say
it
has
to
be
code
from
that
operator.
Maybe
somebody
else
is:
writing
another
one.
Next
year,
I
don't
know,
but
I
think
we
will
meet
people
get
to
that
point
where
we
need
more
logic.
I
I
think
that
if
you're
arguing
from
the
point
of
maybe
if
I
really
want
to
replumb
for
the
purely
kubernetes
experience
with
as
close
to
CF,
but
not
necessarily
slavishly
exact,
then
you
know
you
you
could
make
that
argument
for
the
ground
up,
but
I
don't
think
you,
but
I
would
agree
that
if
you're
saying
I
want
to
get
to
that
hundred
percent,
you,
the
ground
up,
would
eventually
take
longer.
So.
D
Yeah
I
want
to
make
sure
that
everyone
understands
that
we
at
Sousa
know
the
recognized
that
there
is
a
disincentive
to
making
radical
changes
in
the
current
pass
like
using
CF
operator
to
consume.
Bosch
releases
doesn't
force
the
issue.
It
doesn't
rip
off
the
band-aid
and
make
people
reimplemented.
D
D
The
push
is
not
as
strong
if
we
have
something
like
cube,
CF
and
CF
operator
that
can
keep
releases
coming
out
and
can
gradually
change,
Cloud
Foundry
into
a
more
kubernetes
things.
It's
it.
Maybe
it
doesn't
force
the
issue
as
much,
but
it
also
it's
the
only
same
path
that
I
can
see
to
actually
keeping
releases
coming
out
and
having
some
of
us
on
cube
and
some
of
us
not
on
cube
and
then
eventually
all
of
us
on
cube.
D
So
to
also
answer
Eric
question,
I
think
re-implementing,
all
the
components
and
and
starting
from
scratch
on
some
of
these
things
pushes
the
timeline
out
a
lot
further
than
we
are
are
allowed
to.
You
know
I
think
that
the
industry
would
punish
cloud
foundry
for
for
moving
too
slowly
here.
I
strongly
believe
that,
and
if
we're
as
if
we
have
something
releasable,
we
all
have
something
releasable
next
year
that
we
still
have
the
opportunity
to
make
cloud
foundry
relevant
in
the
kubernetes
community.
If
we
wait
too
long,
they're
just
gonna,
ignore
us
completely.
A
A
So
I
think
basically,
we've
continued
discussions.
There
I
still
see
like
two
slightly
different
approaches:
I,
don't
think
that
we
really
came
to
like
this
is
what
we
would
we
jointly
want
to
do
so,
probably,
and
let's
see
what
people's
interests
are
so
I'll
come
up
with
another
poll
for
next
time.
Probably
continuing
on
that
discussion
thread
might
be
something
interesting.
One,
on
the
other
hand,
may
decide
until
then,
or
a
has
some
more
to
to
show.
Let's
see
so
probably
continuing
in
that
direction
is
oh.
D
D
E
Ahead:
Eric,
oh
right,
I
just
wanted
to
say
also
to
confirm
that
sorry,
you
were
gonna
dive
into
more
of
the
cube
CF
and
see
if
operator,
details
on
the
sixth
yeah.
B
So
I
think
well,
I,
don't
I
would
be
one
of
my
questions.
I
guess,
if
I
ask
and
maybe
something
we
can
explore
in
the
future-
is
what
happens
if,
when
we
swap
with
new
releases
or
Ocasek
aid
centric
releases,
they
may
not
have
all
the
capabilities.
So
that
means
you
mean
in
another
Fork
of
cube
CF,
that
is
on
dev
branch
that
will
in
and
then
they
trade
on
it.
B
C
A
good
question:
we
have
these
things
that
we
call
feature
flags
so
like
we,
you
switch
from
Diego
to
ireenie.
You
can
switch
from
Barcia
ireenie
to
hell
my
Rini.
We
don't
plan
to
remove
the
Bosh
irony
from
day.
One
right,
we'll
have
a
feature
flag
that
allows
you
just
like
what
type
do
you
want?
We
need
deploy,
yeah.