►
From YouTube: Config Working Group 6/3/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
I,
don't
know
over
how
much
time
it's
taken
to
explode,
there's
a
table
that
spans
pages
1,
&
2.
That
shows
the
distribution
of
flag
definitions
using
Cobra.
It
gets
quite
complicated
for
our
customers
to
manage
and,
in
particular
within
a
kubernetes
environment.
Cli
flags
are
non
trivial
to
edit
they're,
not
naturally
grouped
into
key
value
pairs.
They
can
be
under
the
command
definition
or
they
can
be
separated
out
into
the
args.
So
it
gets
a
little
bit
difficult
to
manage
there.
A
It's
also,
let's
say
the
total
number
is
over
300,
it's
very
difficult
to
come
up
with
useful
names
that
are
not
exceedingly
long
for
our
flags
with
over
300
names
that
need
to
get
managed.
One
great
example
is
in
gali
introduced
in
1.2.
We
have
the
config
file
flag
and
the
config
path
flag,
which
are
almost
entirely
unrelated.
A
A
However,
in
doing
that,
what
we
don't
want
to
do
is
introduce
a
totally
different
naming
scheme
or
a
totally
different
validation
process
for
the
information
that's
going
to
come
from
a
config
file.
As
far
as
the
process
is
aware,
they
need
to
be
essentially
identical
values,
so
fortunately,
this
is
a
pretty
well
solved
problem
with
a
package
called
VIPRE.
C
A
So
if
we
scroll
down
to
page
3,
we
can
see
some
examples
of
how
config
can
be
specified.
So
one
thing
that
I
haven't
addressed
so
far,
while
VIPRE
allows
us
to
use
exactly
the
same
flag
names
in
a
flat,
JSON
or
yellow.
It
also
gives
us
the
ability
to
specify
aliases
for
flag
names,
so
one
flag
can
be
known
by
multiple
names.
Those
aliases
in
turn,
using
a
dot
delimit,
can
allow
us
to
use
a.
C
Do
we
need
this
feature?
I
mean
I,
think
it
would
be
more
confusing
than
because
the
whole
idea
is
to
use
it
as
a
transition
to
have
everything
moved
to
config
files.
That
operator
will
also
use
and
all
because
anyway,
people
do
not
interfere
with
the
flags.
I
mean
in
the
20s,
a
installers
that
will
set
those
things
and
for
the
Installer
is
much
more
than
difficult
to
have
exactly
the
same
thing.
That's
not
any
aliasing.
C
A
C
C
But
the
whole
the
whole
idea
is
that,
with
the
installer
and
operator,
in
both
cases,
the
user
will
interact
with
wire
mesh
config,
let's
quite
mesh
config
new
name
for
value
jammer.
This
thing
will
be
checked
in
as
a
CR
D
and
will
be
watched
by
operator
and
and
will
be
kind
of
the
source
of
truth
for
everything,
everything
that
is
used
in
galley,
Flags,
environment
or
whatever
is
derived
from
this
particular
file
and
these
settings,
and
it
will
be
available
as
a
config
map
and
can
be,
can
be
mounted
so.
C
A
C
A
Feasible
given
this
technology,
but
it's
not
necessary
so
so
we
can
do
that.
We
can
do
other
than
that
this
technology
or
this
proposal
would
just
give
us
the
flexibility
to
decide
now.
What
I
would
say
is
given
that,
if
that
is
the
overall
direction
that
we
want
to
move
towards,
one
config
file
for
all
of
this
do
the
hierarchical
naming
that
you're
seeing
demonstrated
here
becomes
even
more
important
yeah,
because
you
now
have
all
of
those
names
in
one
file
to.
C
Clarify
that
I
mean
the
direction
is
to
have
to
move
to
operator,
which
will
mean
that,
so
currently
we
have
the
one
config
file,
which
is
values.
Dot
llamo
operator
is
proposing
additional
config
files
that
will
be
defined
part
of
the
operator,
but
it
doesn't
matter
which
one
it
is.
There
will
be
a
set
number
of
well
defines
here.
These
that
defines
a
mesh
configuration
in
operation
and
I
would
hope
that
this
will
be
the
source
of
truth,
because
the
only
thing
is
that
we
interact
with
no
user
would
ever
directly
modify.
B
C
B
Think
it's
crucial
right.
So
take
the
connectivity
example
right.
You
know:
hey
Kovac,
telling
final,
here's
the
mCP
service
that
we
should
talk
to
right,
so
that
needs
to
be
defined
like
co-located
with
private.
Somehow
it
is
part
of
deployment
or
like
a
config
file.
You
cannot
be
read
from
the
sources,
so
there's
a
bootstrap
problem.
C
B
B
C
C
B
B
C
B
I'm
proposing
the
sense
that
all
I
am
saying
is
I
think
if
I'm
hearing
right
the
way
I'm
seeing
this
is.
There
is
two
levels
of
configuration
right,
modern
wise
to
the
component,
especially
for
bootstrap
purposes,
and
there
is
another
configuration
that
is
the
configuration
for
once
once
the
bootstrap
is
that
right,
I.
C
Don't
think
I
agree
with
this
statement,
because
operator
and
installer
are
operating
at
bootstrap
level.
So,
yes,
I,
agree
with
you
that
there
is
a
bootstrap
configuration
and
but
that's
those
values,
not
camera,
and
what
installer
use
design
is
a
simple.
There
is
no
other
use
the
readable
bootstrap.
So.
A
I
I
think
this
is
an
interesting
conversation
that
probably
merits
its
own
design
document
in
discussion.
The
the
designing
question
here
enables
either
yep
planning
it.
So
this
is
the
proposal
at
hand
is
just
to
allow
us
to
source
the
config
for
multiple
avenues
and
then
the
strategy
that
each
component
will
use
to
source
them,
whether
it's
from
one
central
file
or
multiple
files,
where
their
users
are
interacting
with
them.
That's
I,
guess
I
would.
C
C
A
Yeah,
so
definitely
providing
flexibility
provides
the
potential
for
abuse.
For
instance,
if
we
updated
our
installer
to
use
half
command
line
flags
and
half
config
files,
that
would
be
exceedingly
confusing
for
no
apparent
reason,
so
it
doesn't
reduce
the
potential
for
abuse
we,
but
it
also
introduces
a
lot
of
flexibility
up
and
I
think
opportunity
for
improvement
of
the
overall
user
experience
to
be
clear.
C
We
already
do
that
and
I
mean
again.
A
lot
of
things
are
past
easy
because
customize
and
other
tools
work
better
with
the
environment,
variables
and
and
and
the
bootstrapping
in
in
and
voice
using
to
environment
garbage
autopsy.
So
we
are
using
environment
always
quite
a
bit,
and
we
also
have
the
common
line,
flux
and
my
intent
is
to
get
rid
of
command
line
flags
with
this
proposal.
So
everything
will
be
environment,
Arabs
or
config
file
or
config
file
and
may
be
environmental
overrides.
So.
A
A
A
All
right
all
right,
thank
you.
You
can
see
here.
Here's
this
is
the
yamo
file.
This
is
a
JSON
file.
Is
that
essentially,
is
equivalent
to
the
gamma
file
just
comments
and
then,
and
then
on
the
next
page,
you
can
see
a
flat
gamma
file
that
does
not
leverage
the
nested
arguments
are
the
nested
variables
and
then,
finally,
what
the
the
equivalent
command
line
flags
would
be.
A
D
A
The
general
is
technically
an
alias
of
the
other
and
at
that
point
they're
used
equivalently,
but
you
can,
if
I
forget
on
either
and
get
the
same
value
you
can
set.
You
can
even
technically
set
on
the
command
line
flag.
You
could
call
that
mesh
config
file
it'd
be
general
dot,
mesh
config
file,
and
that
would
work
as
well
we're
not
advertising
that
particular
part
you
guys
it
doesn't
make
any
sense,
but
it
is
possible.
A
A
Okay,
so
one
critique
that
we've
heard
of
design
documents
recently
within
Sto
is
that
they
languish
in
the
proposal
phase
and
never
get
formally
approved
or
rejected.
Others
get
implicitly
approved
after
they've
simply
been
presented
to
the
group.
Assuming
silence
is
consent.
Is
that
how
the
config
working
group
wants
to
continue?
Okay,.
B
So
there
are
two
questions
here:
one
is
the
copy
her
finger
of
the
right
place,
who
are
not
approved
this
partially
profitable
so
for
galley
I
think
we
already
discussed-
and
you
know
implicitly
approved.
So
if
you
keep
the
scope
of
the
document
to
configure
group
I
think
we
can't
just
put
our
names
I
can't
my
10
and
mine.
They
might.
We
can
mark
it
as
a
group,
but
I
think
your
anytime
is
to
push
it
for
easier
general,
which
I
think
makes
me
think
that
this
needs
to
go
up
to
the
TOC
level.
B
A
B
F
So
I'll
speak
up
and
make
one
comment
as
I
know:
there's
a
couple
of
people
on
the
call
that
will
probably
back
me
up
I
think
so
what
it
sounds
like
you're
trying
to
do
is
at
least
move
viper
to
replace
Cobra
across
all
of
the
tooling,
which
would
also
be
issue
of
control
and
I
know.
There's
a
bunch
of
work
that
is
ongoing
and
still
ongoing
for,
like
tab-completion
and
going
to
Viper
will
basically
nullify
all
that
work.
So.
A
F
A
His
last
name
escapes
me
anyhow
have
a
button
where
the
nested
property
management
that
allows
things
like
general
mesh
config
that
we
saw
in
the
Amal
and
JSON
files.
That
structure
is
incompatible
with
aliasing,
so
you
could
either
name
the
command
line
flag,
explicitly
with
no
alias
using
dots
for
structure
or
you
could
have
aliases.
But
the
intersection
of
the
two
was
not
compatible.
A
I
introduced
the
pull
request
and
talked
to
Steve
about
the
request,
and
essentially
what
I
was
told
is
that
I
was
welcome
to
take
ownership
of
the
project
and
then
could
merge
it,
and
otherwise
it
was
unlikely
to
be
merged
particularly
soon.
So
after
talking
with
Martin
and
a
few
others
on
the
T
on
the
config
team,
it
was
agreed
that
we
don't
really
want
to
own
like
I.
Certainly,
personally,
don't
want
to
own
it.
A
Config
command
line,
processing,
utility,
foregoing,
that's
not
a
core
part
of
my
mission
at
Google
or
a
core
part
of
this
Tio's
mission.
At
the
same
time,
we
very
much
wanted
to
be
able
to
use
VIPRE
to
accomplish
these
goals.
The
amount
of
code,
duplication
that
this
avoids
I
think
is,
is
substantial
enough
to
justify
maintaining
a
private
fork.
A
Yeah,
it
was
not,
it
was
not
the
way.
I
wanted.
The
conversation
to
work
out
I
would
be
much
happier
to
be
working
directly
on
the
obscene
I
think
that
realistically
Viper
and
Cobra
ownership
is
going
to
be
something
that
needs
to
get
solved
in
the
larger
kubernetes
community,
as
it
is
rather
critical
too
many
tools
that
we
leverage
on
a
daily
basis
and
ownership
is
currently
in
question.
A
B
Okay,
so
one
I
think
I
ever
wants
to
mention
before
the
point
where
this
party
still
cuddle
in
this
might
may
not
be
the
right
model
for
the
most
part,
but
I
don't
eat.
First,
like
you
know,
I
just
tell
you
this.
There
is
I,
don't
think
it's
gonna
change
the
from
like
the
mainline,
behavior
or
mainline
experience
for
users,
but
I,
don't
I,
certainly
don't
see
it
like
config
files
or
environment
perhaps
is
like
you
know,
indeed,
the
primary
usage
model
for
that
tool:
a
noise
right
so
right
where.
A
G
B
Yeah
but
easily
because
any
a
this
I
think
is
still
kind
of
a
config
file
in
your
home
folder.
You
know
in
the
command
line
for
the
config
file
pointing
there
by
default,
your
own
folder,
and
then
it
can
look
like
a
cucumber
or
a
cube,
configuration
there
or
maybe
some
other
settings
that
has
alright
so
I,
think
that
would
be
an
interesting
model.
Yeah.
A
You
cannot
do
that
with
customize
and
the
reason
that
they
gave
to
justify
it
is
they
want
every
run
of
customize
to
be
reproducible
from
source
control
without
the
use
of
a
bash
script,
and
so,
if
we
think
of
that
same
pattern
for
sto
control,
I'm,
not
sure
that
there's
a
one-to-one
correlation
there.
But
you
could
see
some
value
in
having
reproducibility
from
source
control
for
certain
particularly
complex
ISTE
of
control
commands.
We
do
have
64
command
line
flags
to
find
an
sto
control.
A
A
G
Ask
people
what
they
think
my
thought
is
that
it's
not
needed,
but
that
if
it
is
popular
for
the
rest
of
us
geo,
it
makes
no
sense
to
be
different.
Just
because
no
one
will
be
using
the
feature.
I
don't
particularly
want
to
test.
I
read
a
bunch
of
tests
that
are
specific
to
Viper,
but
if
needed,
we
can
do
that.
A
It
does
not
introduce
substantial
changes,
actually
I
reference
in
this
document.
The
pull
request
for
Galli
you'll
see
within
that
pull
request.
There's
some
changes
to
like
documentation,
generation,
and
things
like
that
that
are
one-time
changes
would
not
be
need
to
be
repeated,
as
this
has
moved
out
to
other
utilities.
But
if
you
look
at
the
changes,
just
within
the
gallic
galle
command,
folder
you'll
see
that
the
actual
change
is
necessary
to
accomplish.
This
are
not
extensive.