►
From YouTube: Config Working Group 5.17.18
B
A
Okay,
then,
you
can
have
a
quick
sync
upon
this,
so
just
for
status
or
myself.
I
actually
said
implementing
controls
in
pilots,
which
is
essentially
a
nice
way
to
expose
debugging
information
in
our
system.
Binaries
mix
for
hazard,
so
I
did
the
first
phase.
The
second
phase
is
actually
making
some
modifications
to
control
Z
itself
so
that
we
can
expose
our
three
collections
and
I'm
gonna.
Do
that
to
expose
pilots
on
configuration
collection.
A
So
that's
coming
up
soon,
so
we
also
participated
in
a
bunch
of
discussions
around
teacher
PC
based
protocol
for
configure
a
to
two
components
and
separately.
I
also
started
some
discussions
here
about
maybe
trying
to
support
non
etcd
backends
for
the
API
server.
So
I
think
this
is
been
a
useful
in
a
couple
of
scenarios
so
watch
it's
funny.
C
C
A
A
So,
on
one
side,
on
the
networking
side,
we
are
using
the
higher-level
concepts,
such
as
virtual
service
to
do
altering,
whereas
on
the
mixer
side,
what
we
have
is
a
is
low
level
constructs
like
what
he
causes:
physical
services-
and
you
know
the
physical
topology,
based
information
to
write
policies
with
and
there's
an
impedance
mismatch.
So
he
is
right
now
he
is
not
document
and
trying
to
come
up
with
a
solution
to
reconcile
these.
B
A
C
C
Any
other
I
just
maybe
set
it
off,
maybe
not
that
is
not
dependent
immediately
dependent
on
the
people.
United
api
server,
one
of
motivations
is
to
have
a
bit
better
layering
between
components
and
the
environment
that
they
run
in
should
make
it
easier
to
test
and
then
develop
locally,
but
also
integrated
in
different
environments.
C
There's
also
various
things
we
want
to
just
at
the
same
time,
with
a
better
support
for
version
unit
config
for
sharding,
a
peg
for
include
Canarian
as
well.
So
there's
a
one
doc
that
we're
gonna
review
last
week,
but
we
postponed
it
because
it
wasn't
really
ready
to
be.
If
you
get
for
over
13
distribution,
which
it's
linked
to
some
place
and
our
mailing
list.
C
This
last
week
we
had
a
discussion
working
team
to
see
what
they
would
like
post
went
out
for
their
camping
ingestion
model,
and
that's
what
the
note
set
Osbourne
up
here
cover
basic
ideas
that
we'd
like
to
have
four
components
to
consume
config
through
a
watch
like
API.
It
could
look
similar
to
the
XDS
API
that
envoy
supports.
Well,
they
all
start.
Looking
the
same,
once
you
make
modifications
to
suit
our
requirements.
C
Multiple
dynamic
sources,
so
this
gets
into
the
multi
cluster
work
that
they're
planning
to
do
so.
Specially
pilot
disk
is
consuming
configuration
from
many
sources,
but
at
least
we
could
try
to
converge
on
the
other
mechanism
that
they're
using
for
that
cut
that
consumption,
so
that
it's
just
maybe
it's
just
a
TS
for
everything
and
they're,
just
there
they're
lucky
at
galilee,
they're
looking
at
other
peer
pilots,
maybe
there's
other
servers
that
that
people
write
the
community.
C
B
D
C
Is
a
good
question
and
the
simple
answer
is
yes
and
yes,
which
is
super
confusing
when
I
heard
it,
but
if
there's
they
want
to
use
so
pile
of
one
expose
80s
to
two
on
voice,
so
that
would
be
LDS
already
a
CBS
CBS
pilot
menthol,
so
I
guess
they
have.
Some
planned
have
like
a
tiered
caching
scheme
or
pilot
could
generate
that
same
data
but
serve
it
to
other
pilots
to
distribute
they
already
kind
of
pre
computed
envoy
configuration
so
so
I
kind
of
a
cache
caching
pilot
might
consume
envoy
resources.
C
C
Would
be
as
use
case
right,
but
also
so
that's
the
the
Envoy
is
a
version
of
abs.
At
the
same
time,
how
do
how
do
we
deliver
is
do
config
to
pilots,
and
in
that
case
it
would
be
using
the
alias
framework,
which
is
just
a
subscription
model
where
the
client
watches
a
set
of
resources,
so
we
will
request
and
it
can
a
connect,
those
those
resources
that
it
that
it
receives
from
the
Civil.
C
D
C
C
C
Talking
about
I
think
there
we
have
an
aspiration
that
we
would
reduce
the
number
of
ways
pilot
can
consume
config
today
service
registry
well
on
they
can
fix
either
file
CR
DS
an
in-memory
version.
This
would
be
a
fourth
I
think
over
time,
we'd
like
to
reduce
that
to
as
few
as
possible,
so
aspirationally
a
single
source
of
it
for
consuming
you.
Co
can
take
that
that
may
take
a
while
to
get
to,
and
we
may
end
up.
You
have
having
maybe
two
for
awhile
until
everything
is
battle
tested.
C
So
my
understanding
is,
there
are
some
users
that
are
very
sensitive
to
to
the
latency
involved
in
the
end,
to
end
service
discovery
path
and
what
we
have
today
with
an
in-memory
service
aggregation.
Is
it's
real,
nothing
that
we're
call,
and
so
in
that
case,
if
you
wanted
to
externalize
that
there's
a
lot
of
a
lot
of
issues
that
have
to
be
discussed
if
that's
a
possibility,
but.
A
C
But
it
wouldn't
be
the
only
yes
that's
the
key
is
there's
this.
You
know
you
could
draw
a
nice
diagram
where
everything
comes
to
Valley
and
maybe
that's
one
available
model,
but
there
are
use
cases
where
definitely
short
term.
That's
not
possible
in
longer
term
there's
performance
in
benchmarking.
They
need
to
be
done
to
see
whether
that's.
A
C
It
is
the
ischial
config
that
we
have
today
with
virtual
services,
destination
rules
gateway,
so
there's
also
a
service
entry
and
you,
if
galley
is
there,
another
kind
of
component
is
serving
service
entry
that
that
is
building
the
service
discovery
information
within
pilots.
So
you
could
use
that
exclusively.
If
you
want
to
do
I
think
that's
a
good
goal,
but
you
wouldn't
do
wouldn't
preclude
somebody
from
using
the
built
in
aggregate
service
registry.
The
pilot
has
today,
ultimately
that's
not
much.
We
can
do
they
control
that
from
the
config
working
group.
C
C
If
there's
the
spec
or
any
lesson
online,
if
there's
input
that
well
now
be
tempted
to
gather
it.
So
there's
a
note
doc
here,
which
is
just
from
a
meeting
a
small
discussion.
We
had
the
other
day,
there's
a
larger
config
distribution
dock
that
I
have
that
I'm
going
to
go
and
update
based
on
this
discussion.
That
might
be
a
better
place
to
capture
any
feedback.
You
have.
C
D
So
I
would
say
it
would
be
nice
if
the
framework
that
we
use
to
communicate
between
Galilee
and
Pilate
was
the
same
as
the
framework
that
we
use
to
communicate
with
galley
and
other
other
sto
components.
I
haven't
really
thought
about
the
ramifications
for
four
components
like
mixer
and
Citadel
and
stuff.
Like
that,
you
know.
Are
there
any
sort
of
knee-jerk
reaction
to
say,
like
MoMA?
No
80s
isn't
gonna
work
for
those
those
kind
of
components
idiots
the
framework.
Shall
we
say
no.
C
There
are
changes
we
want
to
make
to
XDS
or
80s,
so
we
look
we're
looking
at
this
from
the
mixer
side
as
well.
So
ideally
we'd
like
to
have
an
abstraction
that
works
for
everybody,
but
we
need
to
look
at
some
concrete
examples
to
do
that.
Mixture
should
work
with
some
changes
to
the
XDS
XDS
doesn't
right.
C
Now
you
can't
do
incremental
loading,
it's
you're
delivering
the
full
state
of
the
world
which
is
okay
for
small
clusters,
but
it
doesn't
scale
well,
there's
a
plan
to
address
that
on
the
Envoy
side
to
do
incremental
loading
and
lazy
loading
of
config,
so
it's
likely
copy
that
there's
also,
but
also
be
useful
to
have.
This
attempt
a
means
to
provide
a
toxin
sort
of
atomic
delivery
of
conveyor
across
resource
types
which
envoy
doesn't
use
right
now,
but
mixture
would
find
useful.
Whatever
you
mind,
that
is
so.
C
The
XDS
is
a
separate
request
response
pair
for
type.
So
it
would
be
something
search
for
make
sure
you
have
a
separate
request,
separate
several
virtual
stream
for
rules,
handlers
and
instances,
but
in
mixtures
case
we
want
those
to
be
delivered
as
a
as
a
group
and
they're
not
adopted
incrementally
so
there's
some
things
you
can
do
to
break
up
base.
I
have
a
continued
bit
in
your
your
request
and
you
will
say:
I'm
delivering
a
sequence
of
responses
and
here's
the
final
one
in
that
sequence,
DJ
and
transaction.
C
There's
a
watch
API
that
the
prototype
with
canned
that
that
that
API
inherently
allows
for
atomic
delivery
any
grouping
this
grouping
mechanism-
the
XDS
doesn't.
But
we
could
add
that
that
could
be
an
optional
thing
for
component.
So
if
mixer
needs
it,
we
use
that
but
pilot
we
could
use
it
on
the
galley
side.
We
could
try
to
sequence
things
and
they
these
should
be
adopted
as
a
group,
but
whether
or
not
pilot
uses
it
that
way
or
just
applies
them
incrementally
is
TBD
yeah.
So
did
your
original
questions
that
we're
considering
multiple
components?