►
From YouTube: CNCF TOC Meeting - 2018-06-05
Description
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
Join us for KubeCon + CloudNativeCon in San Diego November 18 - 21. Learn more at https://bit.ly/2XTN3ho. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
A
B
B
A
D
B
Think
the
lifeblood
of
CN
CF
is
open
source
projects
rather
than
the
sort
of
committees
and
standards
that
we
see.
So
it's
really
important
to
see
living
code,
that's
something
that
can
be
supported
by
cloud
providers
as
well,
and
so
well
done
to
everybody.
Who
did
that
and
thank
you
for
everyone
who
who
participated
in
the
helm,
debate
due
diligence
that
was
important
and
threw
up
some
some
issues
that
we
want
to
talk
about
today,
so
here
on
slide
7.
B
You
can
see
the
issue
that
I
wanted
to
highlight,
which
is
around
the
notion
of
a
sub-project.
Now
kubernetes
has
an
existing
notion
of
a
sub-project
which
I
haven't
linked
to
here
it
could,
there
is
a
proposed
set,
or
you
know,
rules
or
principles
for
how
to
deal
with
sub
projects,
which
is
linked
to
as
a
draft
text.
You'll
see
it's
a
post
by
me
as
comment
on
the
helm,
TOC
due
diligence
issue
and
below
and
above
that
comment.
B
You'll
see
contributions
from
Brian,
Brant,
Quinton,
Brian,
Cantrell
and
also
Matt
Farina,
and
a
few
others
I'm
going
back
and
forth
on
the
that
was
thrown
up,
which
is
this
kubernetes
is
growing
to
be
a
humongous
beast
in
terms
of
its
projects
and
sub
projects,
sakes
and
committees,
and
working
groups
and
what-have-you,
and
you
know
if
it
is
one
of
the
things
we'd
like
to
do
at
CN.
Cf
is
how
can
I
put
this?
B
Avoid
some
mistakes
of
the
move
made
by
projects
large
projects
in
the
past,
and
there
is
concern
that
kubernetes
will
get
unmanageably
big
I
mean
it's
already
running
into
very
significant
issues
of
scale
busts
in
terms
of
its
use
of
github
I
hope
Microsoft
can
resolve
those.
But
now
we've
got
other
issues
like
numbers
of
sub
projects
and
for
kubernetes
to
continue
to
maintain
progress
and
velocity.
It
probably
needs
to
be.
B
You
know
very
lean
and
well-organized
as
well
as
lean
as
it
can
be,
and
so
it's
great
to
see
a
project
like
how
I'm
coming
out
from
under
the
umbrella,
so
to
speak,
of
kubernetes
and
being
its
own
saying,
I'm
fully
totally
supportive
of
that.
But
that
raised
the
question,
which
is
you
know
if
you're
a
standalone,
CN
CF
project?
B
Can
you
still
be
a
project
that
only
works
with
kubernetes,
and
this
has
created
a
number
of
discussions,
including
you
know.
Oh
desist
turn
CN
CF
into
the
kubernetes
organization,
or
you
know,
and
things
like
that.
If
you've
got
a
totally
independent
project
like
an
invoice
or
refuse,
you
know
with
CNC
FPS
welcoming
to
you
as
it
as
it
would
be
to
project
the
world
kubernetes
and
all
kinds
of
things
and
I
think
we
need
to
be
very
clear
with
users
in
the
community
and
everyone
else
about
our
feelings
in
the
TOC
here.
B
So
I
think
if
you
loop,
if
you
read
the
debt
debate,
you'll
see
that
at
least
those
participants
on
the
debate
concluded
that
yes,
CN
CF
should
accept
that
it
will
have
standalone
projects
that
at
least
initially
only
work
with
kubernetes
and
that's
just
how
things
at
the
feet
now.
I
would
like
to
throw
this
open
to
the
TOC.
People
have
dialed
in
and
asked
for
any
strong
opinions
in
either
direction
on
this
matter.
Well,.
C
I
I
would
like
to
just
provide
a
little
bit
more
context,
that's
also
on
the
github
issue.
If
you
look
at
what
happens
in
no
Jess,
just
as
an
example,
the
node.js
foundation
decided
not
to
accept
user
space
JavaScript
libraries
into
that
foundation,
and
then
those
projects
were
sent
to
the
JavaScript
foundation
instead
and
I.
Don't
think
that's
the
situation
we
want
for
those
scenes.
Yes,
another
foundation.
C
For
example,
you
know
either
a
new
foundation
or
like
the
Apache
foundation,
or
something
would
take,
could
be
any
specific
projects,
because
the
CNCs
didn't
want
to
the
kubernetes
project
is
very
large.
It
has
pretty
ubiquitous
industry
supports
and
it
is
inevitable
that
there
will
be
projects
that
are
perfectly
happy
supporting
kubernetes
only
at
least
for
quite
some
time
so.
F
C
I
didn't
do
a
comprehensive
count,
but
I
estimated
that
the
Apache
foundation
has
about
200
projects
right
now.
You
know
that
foundation
is
something
like
20
years
old
and
that
doesn't
include
their
incubator
or
their
labs,
or
you
know
whatever
or
categories
they
have
that's
quite
a
lot
I.
Don't
it's
I
think
it's!
This
foundation
is
a
little
bit
too
young
to
say
whether
we'll
ever
have
that
many
I
think
one
thing
that
came
up
in
the
discussion
is
we
may
need
more
flavours
of
categorization
than
the
current
tiers.
C
We
have
graduated
incubation
and
sandbox,
which
are
more
oriented
towards
project
maturity,
and
we
may
want
to
distinguish
platforms,
strategic
technologies,
other
things
compared
to
you
know,
projects
that
are
simply
useful
tools
in
the
toolbox.
I
think
the
trail
map
is
doing
a
better
job
of
this
than
the
landscape,
but
we
may
need
some
categorizations
of
the
projects
themselves.
Looking
at
Apache,
they
have
categories
of
projects
in
terms
of
the
domain
like
whether
it
does
build
or
it
you
know,
does
data
processing
and
things
like
that,
which
is
definitely
useful.
C
B
B
B
Camille
I
think
that
if
we
start
having
user
space
projects
and
I'll
give
you
one
example
that
was
doing
the
rounds
at
Keep
Calm,
but
it's
just
the
representative
example
is
cube
flow.
Then
we
could
have
thousands
of
those
things
on
the
order
of
magnitude
of
you
know,
high
hundreds,
maybe
over
1000
well.
C
F
F
Has
a
higher
profile
than
having
some
sub
project
in
one
of
the
high
level
projects,
and
so,
if
we
create
a
precedent
where
relatively
smaller
and
in
some
cases,
given
any
specific
projects,
moving
from
kubernetes
and
projects
to
the
CN,
CF
I
think
that
number
could
be.
You
know,
the
rate
of
onboarding
requests
could
accelerate
tremendously
and
if
we
don't
have
a
mechanism
for
accommodating
them,
ie
review,
bandwidth
and
categorizations,
and
you
know
just
ways
of
managing
this
at
the
high
at
the
top
level
on
CN,
CF,
they're,
gonna,
end
up,
homeless
and
I.
F
C
C
F
Yeah
I
think
I
mean
for
every
application
or
infrastructural
component
that
wants
to
run
on
kubernetes.
There
is
likely
to
be
one
or
many
projects
which
gets
fawn
to
to
make
it
easy
to
run
those
things
on
top
of
kubernetes
in
particular,
and
in
future
probably
other
container
orchestration
systems.
I
had
strimm
Z.
It
approached
me
the
other
day.
That
is
a
something
to
make
Kafka
easier
to
install,
run
and
operate
on
communities,
and
you
know
you
could
for
every
project
that
wants
to
run
on
kubernetes.
H
G
G
So
there's
going
to
be
a
ton
of
potential
applicable
projects
and
I
mean
I,
don't
think
we
will
scale
to
having
the
TOC.
You
know
hand
evaluate
every
single
thing
that
wants
to
join.
If
we
really
want
to
want
to
be
the
place
for
cloud
native
projects
and
I
guess
we
should,
you
know,
contend
with
that
at
some
point.
G
H
And
I
think
what's
pulling.
That
intention
is
that,
in
addition
to
not
wanting
to
emulate
necessaries
in
the
bureaucracy
of
the
Apache
foundation,
it,
the
Apache
foundation
does
have
many
projects
that
have
very
little
activity
and
don't
necessarily
have
a
theme
that
they
don't
necessarily
have
anything
to
try
to
unify
them
and
I
think
that
we
do
want
to
avoid
becoming
a
dust
bin
or
projects,
don't
the
Apache
foundation.
H
So
it
doesn't
necessarily
and
they're,
obviously
very
active
Apache
projects,
but
it
also
does
have
the
reputation
as
a
place
where
you
kind
of
kind
of
an
orphanage
for
projects
that
don't
have
another
home
and
I
think
we
do
want
to
avoid
that.
I.
Don't
think!
That's
a
desirable
outcome,
but
I
think
you've
got
a
fair
point
in
terms
of
like
there
are
a
lot
of
projects
out
there
and
we
don't
want
to.
H
C
You
know
they
may
not
necessarily
have
to
live
in
the
CN
CF
if
they
are
related
to
another
existing
open
source
project,
but
add
support
for
envoy
or
Prometheus
or
kubernetes
or
whatever
they
can
live
wherever
the
root.
The
original
project
is,
and
that
may
be
fine,
as
CNCs
projects
become
kind
of
more
widespread
and
more
things
integrate
with
them.
H
And
it
just
finds
your
point
I.
Could
one
of
the
questions
that
you
have
is
what
problem
are
we
seeking
to
solve
by
making
them
CN
CF
projects,
as
opposed
to
just
projects,
open
source
projects
with
and
having
kind
of
a
clear
bar,
for
that
would
be
really
helpful,
absolutely
totally
clear,
but
in
terms
of
what
problems
we're
trying
to
solve
for
the
projects,
yeah.
F
I
was
just
gonna,
say:
I
had
a
similar
kind
of
question
and
proposed
to
answer,
which
is
I,
think
we
need
to
be
clear
who
the
CN
CF
is
trying
to
serve
I
think
there
are
two
kind
of
groups,
the
the
one
is
consumers
of
cloud
native
technology
and
and
I.
Think
in
my
mind,
it's
desirable
to
have
a
kind
of
a
place
where
they
can
go
and
shop
for
things
and
know
that
there
is
a
reasonable
way
of
figuring
out.
F
You
know
what
which
one's
a
high
quality
which
one's
active,
maybe
which
ones
are
incubating,
etc
and
and
be
able
to.
You
know,
have
some
level
of
confidence
that
what
they're
getting
is
is
you
know,
consistent
interoperable
of
a
certain
quality
bar,
etc,
and
then
the
other
group
that
we're
serving
is
the
actual
projects
themselves
who
want.
You
know
home
and
ownership
and
legal
structure
and
support
for
project
management,
etc.
F
And
as
long
as
we
keep
that
clear
in
our
heads,
then
then
we
can
shape
the
rest
of
the
stuff
around
that.
If
we
believe
that
that
those
consumers
need
access
to
hundreds
of
projects,
then
we
need
to
kind
of
pull
ourselves
up
to
be
able
to
about
them.
If
we
don't
think
that
that's
a
requirement,
then
we
shouldn't
rule
ourselves
up
to
handle
Hammonds
project
yeah.
C
There
are
specific
services
that
couldn't
mention
that
projects
are
looking
for,
but
the
most
frequent
issue
that
I
hear
about
is
companies
not
wanting
to
contribute
to
projects
owned
by
their
competitors
or
owned
by
companies
that
are
startups
that
might
disappear
or
get
acquired
by
a
competitor.
Things
like
that
they're
really
looking
for
that
neutral
ownership
of
a
foundation,
and
otherwise
they
don't
feel
comfortable
contributing.
H
B
I
agree:
thank
you.
Everybody
I'm,
just
in
the
interest
of
time,
I'm
gonna
declare
a
halt
to
this
discussion.
Now
I
would
ask
everybody
to
go
and
look
at
the
language,
let
linked
to
as
a
proposed
set
of
principles
on
this
I.
Don't
think
it
covers
all
of
the
things
that
were
said
today
by
Brian
Cantrell
and
Quinton
and
Brian
grant
and
Camille,
and
anyone
else
who
spoke
there's
also
some
good
chat
in
the
IM
window
here,
so
anyone
who's
participated
in
this.
B
Please
go
and
take
a
look
and
see
if
we
can
improve
that
language.
Let's
come
up
with
a
statement
of
our
opinion
here
and
add
that
to
the
operating
principles.
Next
time
we
update
them.
I
think
this
is
going
to
be
more
important
in
the
future.
I,
don't
think
it's
urgent,
because
I
think
that
you
know
helm
is
an
early
indicator
of
this
rather
than
the
beginning
of
a
slew
of
projects.
B
B
Now
we
have
a
project
presentation.
I
need
to
declare
a
conflict
of
interest
here.
So
this
is
a
project
called
we've,
cortex
or
cortex
for
short,
which
originated
and
we've
works.
We
works
is
transitioning
it
or
has
indeed
transitioned
it
to
a
community-based
project.
So
for
the
duration
of
this
presentation,
I
will
drop
out
completely
I'm.
Actually
gonna
pass
my
computer
to
Bryan
Boram
she's
gonna
speak
for
we've
works
as
a
project.
Maintainer
I
believe
we
have
some
people
from
other
projects
on
as
well
to
talk
about
it.
B
I
E
Yes,
good
morning
afternoon,
good
evening,
so
today
we're
here
to
talk
about
cortex,
we're
looking
for
two
sponsors
to
bring
the
CNC
F
to
bring
cortex
into
the
sandbox.
So
what
is
cortex
cortex
is
a
horizontally
scalable,
multi-tenant
Prometheus.
So
when
you
get
this
thing
up
and
running
and
in
a
SAS
monitoring
system
effectively
have
the
ability
to
provide
Prometheus
instances
on-demand
to
your
users,
whoever
those
are
from
a
single
running
instance
of
cortex.
E
You
can
you
can
provision
these
without
having
to
provision
communities,
clusters
of
storage
or
any
of
the
infrastructure
that
you
need,
underneath
that
cortex
is
a
complete
Prometheus
monitoring
system
that
is
API
and
pom
ql
compatible
with
Prometheus.
In
fact,
it
vendors
in
Prometheus
underneath
covers
it
is
highly
available
in
an
architectural,
a
fundamentally
different
way
than
prometheus.
It
is
a
micro
services
based
architecture
that
allows
you
to
fail
the
components
individually
inside
of
the
architecture.
It
is
horizontally
scalable.
E
E
So
there's
a
single
cohesive
system:
this
is
not
a
taut
per
client
sort
of
architecture
and
that
tendency
is
encoded
throughout
the
architecture,
all
the
way
into
the
data
storage
layer
and
we're
also
cloud
native,
as
I
said,
micro-services
based
distributed
hash
table
for
the
right
path,
completely
stateless
on
the
read
path
deploy
to
manage
with
kubernetes
and
works
in
multiple
cloud
and
on-premise.
Equal
storage
engines
next
slide
please.
E
E
Providers
like
myself,
like
we've,
works
for
final
labs,
open
EBS.
These
folks
are
providing
a
system
that
is
enhanced,
metrics
and
monitoring,
teeler
and
customers,
and
they
need
a
multi-tenant
solution
order
to
do
that.
Large
enterprises
on
the
call
today
and
I'm
stuck
in
snow,
Electronic,
Arts
and
storage
OS,
are
using
cortex
today
in
order
to
provide
on-demand
Prometheus
instances
for
large
kubernetes
installations
or
multiple
kinetic
consolidations.
These
are
the
two
types
of
users
that
we've
identified,
who
are
currently
running
cortex
today.
E
E
Long-Term
storage
is
a
fundamental
source
of
value
that
that
users
need
out
of
their
Prometheus
instances
and
Prometheus
itself
does
not
provide
that
gracefully
for
the
enterprise.
Having
a
provide
a
global
query
view
as
an
alternative
to
the
Prometheus
Federation
story
is
super
compelling
and
having
an
alternative
to
the
Prometheus
run.
To
of
everything
everywhere
for
high
availability
is
also
very
nice.
So
the
architectural
decisions
that
came
out
of
cortex
were
more
based
in
these
motivations
Brian
on
to
you
next
slide.
Please.
J
J
Electronic
Arts
is
an
interesting
one.
They
are
not
intending
to
sell
the
thing.
I
turn
aliy
like
the
rest
of
the
people
I
just
mentioned,
but
use
it
internally
anyway,
there's
just
a
flavor
on
the
screen
of
a
bunch
of
people
either
as
end-users
or
us.
People
are
adopting
the
project
from
a
development
point
of
view,
and
we
think
in
aggregate
there's
about
60
million
time
series
being
gathered
by
all
these
different
people
in
in
real
time.
J
J
D
Of
the
project-
yes,
yes,
thank
you,
Brian
hello,
everyone,
I'm
Tom,
one
of
the
original
authors
of
cortex
over
two
years
ago,
and
now,
if
I'm
laps
running
it
running
it
there
so
project
started.
Two
years
ago,
we've
works.
We
did
a
very
rough
sprint
to
get
it
ready
for
prom,
comm
2016
and
had
it
launched
and
gave
demo.
We
then
spent
the
next
few
months,
making
more
production
ready
and
launched
it
into
production
with
a
few
customers.
D
Please,
on
the
community,
we
are
actually
on
31
contributors
now
I'm.
So
it's
still
relatively
small
spanning
around
six
companies.
Total
licenses
Apache
too
and
there's
a
good
cadence
of
pr's
and
a
nice
slack
channel
that
we
all
kind
of
chat
on
pretty
regularly
reviews
are
happening
bugs
are
getting
fixed
generally
pretty
healthy,
I'd
say
of
this
people.
You
saw
on
the
adopters
slide.
D
We
know
for
a
a
definitely
in
production
and
three
of
them
are
are
kind
of
in
the
early
stages
of
going
into
production
in
February,
the
community
effort
sort
of
kicked
off
in
erst.
We
started
a
community
mailing
list,
and-
and
it's
led
to
this-
this
outcome
here
and
Bryan
and
chapter
we've-
works-
have
drafted
a
governance
process
based
on
CNI,
which
I
believe
is
very
close
to
being
merged
as
a
PR.
D
Next
slide,
please.
So
one
of
the
questions
we
foresaw
was:
what's
the
relationship
between
cortex
and
Prometheus?
Well,
as
Bob
covered
cortex
is
API
compatible.
The
two
original
authors,
myself
and
Julius
are
also
prometheus
developers,
and
a
lot
of
the
coding
cortex
is
is
just
Prometheus
code.
We
vendor
it
as
a
library
we
have
up.
You
know
upstream
various
fixes.
The
whole
of
the
remote
write,
API
remote,
read
API
as
well
in
Prometheus
was,
was
more
or
less
motivated
by
cortex.
D
We
did
discuss
upstream
in
cortex
into
the
Prometheus
org
about
a
year
ago,
but
the
Prometheus
team
decided
against
it.
I
was
part
of
that
decision.
Long
term
storage
is
explicitly
a
non
goal
of
Prometheus.
The
Prometheus
team
has
limited
bandwidth
to
deal
with
newer,
newer
projects
and,
and
they
really
don't
to
be
kingmakers,
and
they
thought
the
implicit
blessing
of
adding
cortex
to
the
organization
might
put
off
other
projects.
D
J
J
C
J
J
We
could
certainly
take
that
away
as
an
asked
to
put
more
detail.
Yeah
Tim
Bowers
is
a
pretty
new
small
scale.
Project
really
and
m3/d
be
probably
very
interesting
again
quite
newly
announced
it's
using
a
lot
of
the
same
ideas
like
the
so-called
guerrilla
compression
things
like
that
as
Prometheus
and
cortex.
E
E
E
Lot
of
that
is
bring
your
own
depending
on
the
application
of
the
the
end
user
as
they
need
it
and
how
to
apply
fundamentally
within
the
architecture.
You
provide
your
tenant
ID
into
the
rest
of
as
an
HTTP
header,
and
that
is
propagated
through
the
architecture
and
into
the
storage
layer.
So
the
the
multi-tenancy
is
cooked
into
the
architecture,
but
authentication
is
up
to
the
end-user.
D
C
J
The
way
it
works
is
the
the
there's,
an
ingestion
engine
which
does
the
the
compression
of
the
time
series
into
into
what
we
call
chunks,
which
are
a
small
number
of
K,
and
then
those
are
shipped
off
to
the
store,
which
is
one
of
dynamo,
DB
or
Cassandra
or
Google
BigTable.
So
so
that
does
that
split,
basically,
that
the
the
metrics
are
turned
into
chunks.
The
chunks
are
sent
to
a
store
which
is
itself
scalable
and
there's
an
index
as
part
of
that
store.
E
E
H
K
I'm,
just
unmuted
myself,
so
I'm,
probably
a
pretty
large
installation
of
cortex.
So
we
use
it
exclusively
internally
to
monitor
all
of
our
game
servers
which
a
good
chunk
of
our
infrastructure
uses
was
using
prometheus
previously
now
we're
using
cortex
to
basically
pull
that
data
up
and
monitor
our
game
service
across.
K
H
K
So
that's
kind
of
an
interesting
question:
I
hadn't
thought
about
that
one
I
personally,
in
our
inner
and
professionally
in
our
team.
We
use
all
that
a
lot
of
the
tools
from
CN
CFL
radius
would
be
great
to
include
cortex
in
that
sort
of
toolbox.
If
you
will
so,
we
can
participate
with
with
with
this
project,
but,
along
with
the
other
ones,
is
everything
we
deploys
on.
Kubernetes
were
using
Jager
tracing
there's
a
few
other
ones.
I'm
just
blanking
on
right
now,
but
helm
is
another
one
we're
using
heavy
on,
but.
H
K
E
I
think
it's
it's
more
around
standardizing
the
government,
the
governance
model,
so,
as
we
have
on
the
the
slide,
that's
being
shown
here
clearly
there's
some.
You
know
marketing
that
comes
along
with
that
and
vendor
neutrality,
so
we've
works,
wants
to
help
expand
the
scope
of
the
community
around
this
and
bringing
them
into
this.
The
ncf
will
will
definitely
definitely
help
that
and
because
Prometheus
does
not
necessarily
want
to
want
to
touch
it.
Yet
we
figured
that
the
CNC
F
would
be
a
great
place
in
order
to
achieve
all
of
those
goals
together.
L
Hey
sorry,
this
is
Dave
Spotify
just
to
go
back
to
the
value
to
end
users
of
it
being
a
cnc
project.
I
mean
I've
personally
been
trying
to
talk
to
a
lot
of
people
better
qualified
to
start
looking
at
four
media's
and
looking
at
cortex
and
I
think
presenting
cortex
to
group
people
that
aren't
very
familiar
with
this
community
as
a
project
owned
by
weave
works,
which
is
a
company
they
may
or
may
not
have
ever
heard
of
nothing
for
his
community
gets
me
kind
of
ignored,
whereas
I
think
something
as
a
CN.
L
H
Okay,
that's
helpful,
thank
you
and
then
from
I
I
guess
another
question
for
both
you
and
for
EA,
from
kind
of
a
user
perspective.
Do
you
view
cortex,
as
kind
of
a
part
of
your
permit?
The
way
you
think
about
prometheus?
In
other
words,
does
the
project
distinction
here?
Does
that
help
you
or
hinder
you?
I
mean
I,
understand
that
it's
a
Prometheus
teams
decision
to
actually
not
include
this
functionality,
but
from
your
perspective
should
do
you
think
of
these
as
separate
projects.
K
L
Yeah
I
think
for
us
for
me
personally,
I
see
them
as
separate
projects
but
I
think
part
of
the
point
for
kind
of
convincing
Spotify
to
switch
from
our
own
homegrown
monitoring
stack
to
something
like
Fermi
fact
becomes
the
same
thing,
because
if
they
see
Prometheus
alone
has
some
set
of
flaws
like
level
scalability,
for
example,
and
quarks,
all
those
mostly
Spotify,
it
really
just
means:
okay,
I,
don't
care
if
you
call
it
cortex
or
something
else
really.
Just
you
gave
me
for
me:
theism,
it's
scored,
lovely
skin,
but
to
me
personally,
I
can
spirits.
K
And
yeah
that's
and
that's
a
good
point.
A
lot
of
our
users
internally,
probably
in
our
in
our
various
companies,
probably
wouldn't
know
the
difference,
because
they're
just
looking
at
a
graph
on
a
dashboard
where
the
data
comes
from
they're,
not
really
visible
to
that
information.
But
to
us
who
know-
and
they
I
assume-
is
two
separate
projects
right.
H
H
H
Because
I
mean
honestly,
we
have
in
here
we
have
the
kind
of
the
similar
conundrum
that
that
what
we
have
with
helm,
where
you've
got
something
that
is
important
to
the
project
and
specific
to
it,
but
feels
it
has
a
separate
identity
and
I've
got
kind
of
similar
concerns
in
terms
of
of
adding
complexity.
To
I
mean
I.
On
the
one
hand,
I
don't
want
to
force
a
union
where
one
does
not
exist.
On
the
other
hand,
I'm
I'm
loath
to
add
more
complexity
to
the
CN
CF
landscape.
H
A
Cool
I
just
want
to
be
scented
at
the
time,
since
we
have
one
more
quick
presenter
after
this
formally,
if
you're
interested
in
sponsoring
the
project,
please
let
them
know,
but
for
now
I
think.
That's
it
thanks
for
your
time.
Thank
you.
Everyone
go
I'll,
kick
off
a
thread
on
the
mailing
list
to
where
people
could
ask
questions,
because
there's
a
lot
of
questions
in
chat
so
for
right.
Now,
thanks
Bob,
Tom
and
folks.
Now,
let's
have
William
talk
about
linker
d,
2o
+,
conduit
plans,
hey.
B
M
M
As
you
can
see,
it's
basically
to
take
the
code-behind
conduit,
merge
that
into
linkage
then
do
a
little
bit
more
engineering
work,
release
that
as
link
or
D
2.0,
and
at
the
end
of
that
process
the
conduit
project
goes
away
and
the
con
would
brand
goes
away
and
everything
is
now
back
to
linker,
D
and
the
reason
I
wanted
to
talk
about
this
in
front
of
the
TOC
is
because
I
know
when
we
started
conduit.
We
had
some
discussions
with
you
folks
about
conduit
itself
being
kind
of
a
top
level
or
being
a
project.
M
M
So
I
just
have
a
couple
kind
of
very
quick
I,
think
use
and
then
I
I
would
I
figured
I
would
answer
kind
of
leave
it
the
rest
for
QA,
but
the
goal
basically
for
us
is
when
we,
when
we
started
con,
with
the
reason
why
we
decided
not
to
kind
of
do
it
as
a
as
a
link
we
D
sub-project
or
to
do
it
as
part
of
link
with
you
at
all
was
effectively.
We
weren't
sure
that
it
was
really
going
to
work.
M
They
were
making
a
bunch
of
fairly
risky
decisions
and
I
think
there's
a
nonzero
probability
that
it
would
just
fail.
Now
that
we're
you
know
eight
or
nine
months
into
it.
Happily,
no
no
that's
happened.
Condor
is
actually
in
really
great
shape
and
the
goal
of
merging
it
into
two
link
or
D
is
that
basically
link
or
do
moves
in
a
future
with
a
dramatically
reduced
resource
footprint.
So
linker
to
you
right
now
is
on
the
JVM.
There's
lots
of
cool
stuff.
M
We
can
do
especially
with
things
like
graaah
vm
coming
out,
but
ultimately
we
need
to
be
able
to
operate
link
to
be
in
a
way
that
doesn't
require
you
know:
200,
200,
Meg,
proxy
or
150
Meg
products,
or
even
a
30,
Meg
proxy
and,
like
I,
said,
the
reason
do
this
now
kind
of
codebase
has
reached
kind
of
viability.
It's
no
longer
a
totally
alpha
tuned,
experimental
thing,
and
then
you
know
conduit
goes
away
at
the
end
of
this
and
the
existing
linker
decode
base
contains.
M
It's
kind
of
totally
different
from
link
ID,
it's
a
new
code
base
and
a
fairly
different
UX.
But
a
lot
of
the
core
team
is
the
same.
The
goals
of
the
project
I
think
they're.
Both
service
meshes,
the
value
props
around
reliability
and
security
and
visibility
are
all
entirely
the
same.
The
general
architecture
of
control,
plane
and
data
plane
are
all
the
same
and
you'll
be
able
to
migrate.
M
I
think
there's
a
the
Devils
in
the
details,
the
the
initial
verse,
for
example,
an
initial
version
of
of
what
would
be
linker,
D
2.0
will
be
kubernetes
only,
and
so
the
many
linker
to
users
link
to
d1
9x
users,
who
are
not
on
kubernetes,
will
have
a
hard
time
approving
or
migrating,
but
over
time
will
start
adding
more
and
more
to
the
project
and
capture
all
the
other
news
cases
as
well
and
then
finally
yeah.
That's
it.
That
is
that
the
code
would
live
in
the
and
the
winter
deed,
github
org.
M
N
N
Yeah
I
guess
in
William
I
both
appreciate
the
the
notion
that
conduit
was
originally
asked.
You
know
allow
its
perspective,
or
you
know
you,
the
maintainer
perspective
incoming
even
CNCs,
and
some
in
many
respects,
like
it's
just
sort
of
a
natural
motion
to
follow
up
on
that
inquiry,
but
but
appreciate
you
know
the
team
bringing
this
in
from
the
TOC
sustenance
such
that
folks
don't
receive
it
as
you
know,
being
slipped
in
to
the
extent
that,
in
my
mind,
like
one
of
the
more
prominent
concerns
here
is.
N
M
I
think
it'll
be
less
around
kind
of
demon,
fit
versus
sidecar
and
more
around.
How
complex
is
your
link
or
D
1
dot,
X
routing
configuration,
and
are
you
running
it
on
what
what
are
the
environments
that
you're
running
it
on
because
you
could
get
you
can
get
very,
very
complex
with
like?
Do
you
want
on
X
right?
One
is
one
of
the
strengths
is
strengths?
Is
you
can
have
it?
You
know
kind
of
join
a
mazes
cluster
and
the
kubernetes
cluster,
and
you
know,
and
a
nomad
cluster
altogether
and
to
kind
of
unified.
M
You
know,
service
discovery,
framework
and
that'll
be
I.
Think
those
super
complex
situations
will
be
the
hardest
to
migrate
over
because
of
one
people
to
support
all
those
environments.
The
easiest
stuffs
did
migrate
over
will
be
like
overusing,
reusing,
linker,
Dion
kubernetes
and
we're
not
doing
anything
that
that's
particularly
crazy
and
we
have
kind
of
an
engineering
goal.
We
have
this
thing:
if
you,
if
you
search
for
the
linker
D
consolidated,
kubernetes,
config
you'll,
see
this
giant.
M
N
Thank
you
for
reflect
for
a
moment.
There
are
other
projects
that
have
undergone
similar
like
fairly
massive
architect
memory
architectures.
If
we
think
about
like
Prometheus
GSD
be
the
2.0
granted,
it
wasn't.
Necessarily
you
market
of
a
branded
is
something
else,
but
but
I
view
that,
as
almost
almost
is
you
know,
disruptive
is
potentially
and
Lincoln.
Edx
is
so
there's
some
prior
art
here.
A
A
E
A
C
C
N
Me
just
quickly
and
one
of
the
concerns
in
the
community
when
conduit
was
it
initially
his
last
well,
not
this
last
keep
on
going
before
was
you
know
some
people
interpreted
that
as
well.
You
know
there
goes
like
your
D
and
and
just
sort
of
the
implicit
now
under
that
announcement
made
around
the
deprecation
of
Lincoln,
DISA
I.
Think
for
the
end,
there's
any
number
of
large
users
of
Lincoln
who
now
you
know
in
this,
this
form
don't
receive
a
much-improved.