►
From YouTube: Config Working Group 1.25.18
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).
C
C
B
B
Yeah
all
right,
so
so
today's
meeting
agenda
we're
gonna
talk
about
three
things.
The
first
is
we
had
a
design
summit
last
Friday
and
we
made
a
bunch
of
decisions
and
we're
gonna
going
forward
that
is
to
config.
So
I
will
recap
that
decisions
that
may
probably
takes
me
like
a
minutes
and
after
that
I
was
gonna,
show
what
we're
gonna
do.
Next
was
galley
and
basically
it's
the
first
ever
baby
step.
So
we
can
get
the
ball
rolling
in
the
last
15
minutes.
So
we
would
do
some
charging
of
the
issues
for
the
conflict.
B
B
So
for
those
of
you
who
didn't
attended
on
design
summit,
we
were
talking
about
all
five
areas:
input,
transformation,
distribution,
application
of
the
config
and
and
made
a
lot
of
decisions
on
what
we
gonna
do
and
what
we're
not
gonna
do
so.
The
input,
wise
I
think
there's
two
importance
and
if
you
can,
we
made
one
is
under
scoping
and
that's
about
how
we
upper
scope
and
configure
resource
and
decide
how
this
scoping
will
affect
the
runtime
and
the
runtime
endpoints
of
of
these
configurations.
B
So
we
decide
there's
three
layers
of
scope
and
global
namespace
which
aligns
with
the
kubernetes
scoping
and
we
will
do
a
service
level
scoping,
but
how
we
do
service
level
scoping.
We
are
still
in
the
discussing
and
we
may
not
do
it
in
the
in
the
in
the
first
few
releases,
but
that's
the
topic
of
we'll
continue
working
on.
B
So
if
we
stay
with
that,
so
we
are
not
going
to
do
it
and
we
decide
if
we
expect.
If
we
want
the
users,
you
don't
want
to
be
more
sophisticated
here,
rocky
coast,
coping
building,
more
complicated
icons,
policies
on
top
of
this
they're
gonna,
they
can
use
an
external
source
control
system
tunity.
To
do
you
actually
like
this
any
questions
on
the
input.
B
B
So
I
think
so
what
he
decided
is
we're
gonna
support
the
kubernetes
api
and
compatible
environment,
which
means
even
if
non-carbonate
is
in
API
server
and
again
in
kubernetes.
Namespace
resource
has
been
there
and
it's
also
in
scope.
So
if
there's
an
environment,
that's
there's
no
such
namespace
resource
yeah.
I
don't
know
how
to
do
it
now,
but.
C
I
think
there's
a
realization
that
we
need
to
support
more
advanced
scenarios
as
well,
where
the
conflict
may
live
in
a
richer
medium
that
is
implemented
by
an
enterprise
right.
So
there's
a
desire
to
make
sure
that
those
kind
of
scenarios
work
so
I
think
we
will
not
essentially
be
able
to
try
to
shoehorn
those
kinds
of
scenarios
into
a
just
the
namespace
space
normal.
Does
that
make
sense,
yep.
B
D
B
B
B
Basically
says
when
we
do
a
robot,
so
we
rule
out
too
and
every
and
services
that's
in
that
namespace
effectively
the
snapshot
that
will
grab
or
the
configure
resources.
That's
for
the
namespace
to
be
rolled
out
and
and
the
world
when
sentry
galleon
and
to
to
do
the
robot.
So
all
the
namespace
said
and
the
config
so
a
crossing
like
a
global
or
namespace
that
will
be
flattened.
B
There
will
be
no
runtime
resolution
of
the
scoping
if
the
user
want
to
have
fewer
services
or
names
Bay,
and
so
so,
if
the
user
wants
you
having
like
a
live,
account
shows
for
certain
services
that
I
could
just
achieve
something
similar
to
row
out
for
service.
They
can
do
things
like
putting
one
service
into
your
namespace
or
just
create
a
lot
of
namespaces
and
having
fewer
servicing
there,
and
they
can
do
something
like
that.
You
achieve
the
same
effect,
but
into
design-wise.
E
C
C
But
the
idea
is
you
don't
want
to
try
to
create
like
this
full
global
snapshots,
which
would
actually
be
very
large
and
very
prone
to
change,
because
there
will
be
multiple
updates,
so
you
can't
have
it
like
a
total
configuration
for
diminished
right.
So
the
only
scope
of
transaction
that
actually
is
meaningful
is
essentially
a
service
level
or
a
configuration
of
something
that
an
operator
actually
cares
about.
Right,
I,
understand.
E
E
C
I
think
so
personal
thing
all
right,
so
the
namespace
gives
you
a
controller.
This
is
this
is
a
special
orthogonal
to
the
actual
domain
types
all
right,
so
indem
in
this
domain.
You
have
services,
maybe
rules
and
things
like
that.
Namespace
is
kind
of
an
organization
like
like
mechanism
for
texana
right
and
it
just
so
happens
to
be
a
convenient
one,
because
you
can
use
our
back
to
do
certain
things.
It
also
makes
sense
to
actually
apply
a
snapchat
logic.
B
B
C
Yes,
so
essentially
I
your
point
right,
so
your
point
is
essentially
I.
Think
I
can
apply
Eccles
at
the
namespace
level.
That's
the
no
stranger
to
I
can
get,
but
that
doesn't
necessarily
mean
the
rollout
should
actually
be
within
the
same
time.
It
can
be
something
more
radiation,
x-ray
and
I.
Think
it's
a
very
fair
point
right,
but
to
be
able
to
do
the
snapshot
at
a
smaller
Berninger
to
be
had
to
start
with
the
namespace,
and
then
you
see
if
we
can
provide
something
smaller.
B
On
conflict
distribution-
and
so
there
are
some
important
decisions
also
being
made
and
is
the
automatic
state.
Robot
is
the
out
of
the
scope
so,
but
we
cannot
having
the
conflict
API
to
allow
us
to
specify
the
state
that's
necessary
for
participating
in
a
state
robot,
so
that
will
be
kind
of
resource
by
resource
some
of
the
resource
as
I
showed
somewhere.
B
It's
like
a
routing
rules
like
a
percent
of
Rodimus,
it's
already
sufficient
whether
some
of
the
resource
is
still
not
so
we
need
to
have
some
design
for
that
and
that
another
decision
is
the
high
level
galley
architecture,
so
galley
will
getting
all
the
inputs.
So
this
important
thing
is:
there's
a
separations
of
the
CR
DS
as
the
input
and
and
the
the
series
that's
being
watched
by
the
components,
its
architecture,
its
this
to
storage,
but
increment,
wise,
some
other
boxes.
That
can
be
actually
all
together.
But
this
is
just
your
logical
component
view.
B
C
Yeah,
first
of
all,
I'd
like
to
apologize
for
like
not
sharing
the
documents
beforehand.
The
meeting
that
you
know
is
essentially
it's
written
like
very
late
yesterday,
so
that
was
really
not
much
time
to
share
this.
This
is
really
a
straw
man.
Let's
gather
some
feedback
on
this
approach.
Kind
of
documents
so
don't
take
this.
Is
it
like
a
kind
of
done
deal
if
you
can
poke
holes
in
this
story?
Please
do
so
so
the
basic
idea.
C
C
Here
as
well,
just
in
case
there's
kind
falsifications
about
okay
yeah,
so
the
main
idea
is
okay.
How
can
we
get
this
started
in
this
space
right
there
rather
than
doing
a
Big
Bang
approach?
Can
we
actually
come
up
with
a
incremental
and
principled
approach
right
and
the
biggest
like
the
Tonys
issue
that
we
run
into?
C
Is
this
set
current
set
of
CDs
the
current
set
of
resources
that
we
have
to
configure
the
our
components
are
really
this
like
both
our
public
API
and
also
our
distribution
methods,
so
which
means,
if
you
want
to
change
our
distribution
mechanism,
we
immediately
run
into
some
hurdles
with
okay.
You
either
need
to
create
some
like
horizontal
stack
across
the
board,
or
we
can
only
do
incremental
changes
and
which
is
very
hard
to
implement
right.
So
the
idea
is
okay.
Can
we
actually
separate
this?
C
Can
we
actually
separate
the
distribution
aspect
from
the
public
API
aspect
and
the
idea
is
really
simple:
I'm
just
gonna
scroll
down,
so
this
actually
kind
of
explains
the
problem
right.
This
is
the
public
API
and
the
distribution
mechanism
are
the
same
and
the
idea
is
actually
okay.
Actually,
the
set
of
three
sources
that
either
side
consumes
and
just
have
a
just
as
a
starting
point,
just
as
the
clicks
top
zero
I
have
something
that
copies
from
one
set
to
the
other
one.
C
So
this
seems
like
a
bit
of
extrovert
like
on
face
value,
but
I
think
it
is
important,
because
if,
if
we
can
lend
this
by
the
time
Easter
v1
ships,
we
can
also
ship
a
Kelly
alpha,
one
which
is
an
add-on
component.
It
actually
used
the
same
set
of
resources.
It's
an
opt-in
components
and
if
you
opt
in,
you
are
not
changing
your
verge
flow
in
any
way.
C
It's
the
same
set
of
resources
at
least
you've
even
exposed,
but
as
we
shape
this,
we
can
so
your
public
API
essentially
stays
the
same,
whether
you
use
jelly
or
not
or
or
this
new
confident
that
happens
to
be
named,
gathered
right
so
once
sto
v1
ships,
essentially
this
is
are
like
jelly
is
an
alpha
stage.
This
is
our
a
gas
surface
or
a
PS,
and
our
distribution
model
is
separates
components
now,
but
identical
right.
C
So
once
Galli
reaches
GA
and
becomes
the
the
front
ends
for
config
consumption
or
config
api,
then
we
can
actually
start
considering
the
distribution
as
an
implementation
detail.
So
the
current
set
of
resources
becomes
our
config
model,
v
0
or
V
1,
depending
on
where
you
put
the
index
and
it
is
stable,
you
can
use
it
to
configure
the
system,
but
the
components
that
are
not
really
consuming
this.
This
format
separately.
This
also
allows
us
to
create
either
an
enhanced
model
or
a
completely
new
one
on
the
side
that
just
stops.
D
Yeah
I
think
yeah
I
mean
at
least
at
least
to
me.
It
does
just
make
sense.
One
one
thing
which
I
have
been
you
know
Martin
actually
kind
of
advocating
is
that
we
already
have
multiple
components
like
multiple
data
path,
components
consuming
from
whatever
the
configuration
place
of
recordist,
which
happens
to
be
a
PS
over
right
now,
so
as
a
and
mixer
is
is,
is
probably
is
the
the
main
one
right
now.
D
So
it
would
really
be
good,
not
necessarily
as
part
of
this
work
but
related
work
for
mixer
to
also
be
configured
by
pilot
because
pilot
configures
data
path,
components
component,
just
like
n
boy,
and
once
we
do
that,
then
mixer
doesn't
really
care
about
kubernetes,
APRN,
any
other
API
and
then
the
stuff,
all
this
kind
of.
Even
behind
that.
So
then
only
pilot
really
consumes
from
whatever
the
thing
is,
and
it
and
followed
is
already
distributing
configuration
to
invoice,
and
it
does
so
for
I.
D
C
B
C
C
D
D
We
can
switch
one
independently
switch,
the
other
or
in
any
any
way
way
we
like,
but
I
I'm,
definitely
like
I
definitely
want
to
have
mixer
being
configured
by
parallel
because
it
like
architectural,
it
makes
sense
right
next,
I'll
that
is
supposed
to
configure
the
data
plane,
a
data
path,
components,
and
there
is
no
reason
for
mixer
to
have
its
own
thing,
and
actually
it
makes
some
of
the
other
stuff
very
much
possible.
It's
if
pilot
is
aware
of
is
in
charge
of
doing
those
two
things.
At
the
same
time,.
D
Absolutely
I
think
I
think
we
should
be
able
to
model.
You
don't
invoice
today's
API,
because
there
is
a
lot
of
analog
between
filter
config
and
our
adapter
config,
so
they
so
that
that's
something
I
I
wanted
to
I.
Don't
know.
Did
this
quarter
but
again
it's
it's
orthogonal,
but
the
reason
I
mention
it
is
because
it
affects
the
it
affects
the
overall
picture
in
in
a
positive
right.
It
can
be
slit
streamed
in
any
time.
E
C
A
A
C
So
yeah
it's
kind
of
a
joke
right,
so
yeah,
the
you
know
you
don't
want
to
destabilize
is
top-1
like
that.
Absolutely
and
you
don't
want
to
actually
be.
You
may
want
to
be
a
nimble
as
well.
So
a
feature
branch
makes
I
think
total
sense
to
get
started
on,
but
hopefully
for
me,
one
lens
galley
will
be
become
part
of
the
main
branch.
At
least
that's
what
I
think,
but
it
will
be
in
other
component.
B
B
B
E
B
The
only
reason
is
this
is
the
first
time
as
a
recharging
other
issues,
so
we're
looking
to
the
issues
that
comes
with
working
group.
So
that's
why
we
kind
of
did
together
and
there's
a
lot
of
issues,
so
is
also
historical,
but
over
time
are
we
were
moving
this
to
a
well-established
the
process.
So.
E
B
C
Forward
it
makes
sense
so
I
think
you
need
to
do
this
one-time
thing,
and
we
can
spend
some
time
here
or
you
know
we
cannot
suspend
offline,
but
going
forward.
I.
Think
there's
going
to
be
a
set
of
issues
that
needs
to
be
discussed
in
parts
of
triaging
would
be
figuring
out
what
those
issues
are
and
bringing
them
to
the
table
in
in
this
meeting
and
discuss
about
it.
So
so.
B
E
B
D
E
D
A
E
E
B
B
D
E
E
B
A
D
E
D
E
B
Okay,
so
looks
like
Jason
gonna.
Take
him
for
most
of
the
bugs.