►
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
Hi
everyone
and
welcome
to
the
Cuban
officials
meeting
of
4th
of
July,
and
yes,
there
are
only
from
what
I
think
European
people
here
can
see.
Your
folks
are
on
holiday.
Today,
we're
gonna
talk
about
the
configuration
changes,
we're
about
to
do
incubate
them
in
112
and
I.
Think
I
could
just
go
ahead
and
share.
My
screen
is
that
is
okay
by
everyone
and
we'll
look
a
bit
on
maybe
on
the
cap
and
all
the
peers
that
are
happy.
Merchants
are
up
about
to
be
merged.
B
A
A
So
hence
when,
when
upgrading,
we
we
needed
to
seal
in
kind,
an
API
version
automatically
to
the
version
one
over
one
API,
but
we
can
now
remove
this
hack
and
require
type
meta
being
set
by
default.
So
that
means
we
can
get
a
lot
of
get
rid
of
a
lot
of
code
here
and
now,
if
we
or
we
try
to
detect
the
unsupported
version
the
beginning.
So
if
we
here
we
extract
from
the
bytes,
we
extract
the
API
version
and
if
it's
unknown
old,
API
version,
we're
gonna,
say
use
cubed
and
111
to
perform.
A
The
conversion
of
this
file.
Kiss
cubed
in
111
can
upgrade
version
1
of
1
files
version.
1.
Also,
then,
upgrade
update
the
round-trip
unit
tests
we
have
inside
of
config
or
util
config.
We
have
a
unit
test
that
reads:
whereas
files,
for
example,
here
it's
red
version,
1
over
1,
without
type
error
and
made
sure
it's
identic,
the
internal
demo,
here
after
conversion
and
version
of
a
tooth
internal
and
the
upgrade
case
where
we
read
version
1
of
1
converter,
its
internal
and
rolled
out,
this
version
1.
Also
it's
a
trap.
A
It's
a
trap
and
we
didn't
need
that
that
was
version
1,
also
one
specific.
So
what
do
these
look
like?
We
have
the
version
104
1
spec
thank
God,
then
converted
into
version
104,
and
with
this
with
this,
we
can
get
like
the
end-to-end
flow
of
the
configs,
how
they
are
actually
used
within.
It's
like
an
ET
flow
with
the
convicts,
and
here
we
have
a
function
for
extracting.
If
you
have
version
it
kind
from
yellow.
A
So
that's
mostly,
this
PR
was
the
first
one
to
merge
yesterday
and
it
then
stopped
like
made
cubed
and
not
use
the
version
104
one
API,
but
the
PR
to
actually
remove
the
version.
One
offer
one
folder,
as
can
be
seen
here.
It's
only
deletions
just
it's
just
an
errand
of
the
director
is
here
and
after
this
we
have
instead
we're
adding
version
103
and
the
plan
is
to
when
version
of
it.
A
If
we're
confident
in
this
version
to
be
better
on
a
better
level,
we
can
just
rename
this
in
the
end
of
the
cycle.
We
have
to
do
it
before
code
freeze,
but
if
we,
if
we
are
able
to
code
it
in
a
way
that
it
supports
all
the
features
we
need
before,
as
described
in
the
cap
before
the
code
freeze,
we
can
just
rename.
A
Yeah,
it's
a
stem
cell
here
we
we
need
to
do
the
booster
token
to
GI
stuff.
Definitely
gonna
do
that,
but
but
in
a
later
PR.
So
what
is
needed
to
create
a
new
API
for
cubed
M,
first,
just
copy
the
version
one
or
two
directory
into
and
like
with
with
the
version
1
version
1
of
a
3
package
name.
That
is
literally
what
I've
done
here
to
CP
and
rename
all
package
names
after
that
I'm
starting
to
use,
use
version
1
off
the
tree.
A
A
That's
it
done
the
same
for
node
config
and
here
is
the
exactly
identical,
except
for
all
of
the
tree
there.
It's
like
that
was
added
and
the
same
for
the
node
configuration
ok,
so
that
is
so
far
so
good,
automated
bump.
From
version
one
offer
two
references
to
version
103.
So
in
order
to
make
you
better
Muse
version,
one
off
the
tree
everywhere,
I
just
did
a
final
replace
everywhere.
A
A
A
Yes,
there
we
go
so
we
want
to
have
something.
We
want
to
split
cluster
and
Linnaeus
configuration
in
two
pieces.
So
one
with
the
really
the
cluster
level
configuration
now
master
configuration
is
kind
of
a
hybrid,
it
hosts
tells
the
component
config
hosts
all
the
cube
atom
in
its
runtime,
the
execution
level
stuff,
and
it
holds
the
decide,
cluster
state
and
everything.
A
To
what
your
joining
or
master
your
initializing,
what
else
yeah
so
the
component
config
goes
here
and
as
new
component
configs
are
available,
we
can
just
add
support
for
them
as
separate
the
undocumented
and
not
or
all
stop
respecting.
So
like
the
now,
we
do
X
drugs
for
the
control,
plane,
components
eventually
we're
gonna
be
able
to
say
here
kind,
cube,
API
server
configuration
and
API
version,
cubed,
API,
server,
config,
okay,
that
I
own
version
103.
A
This
is
like
115
or
something
so
kind
of
a
long
way
to
go
here
still,
but
once
this
is
available
and
we
can
use
it,
it's
just
a
matter
of
a
new
young
document,
and
if
this
then
is
specified
the
extra
axis,
we
can
say
that
the
X
Box
is
not
respected
or
something
like
that,
and
that
will
be
the
like
migration
plan.
It
should
be.
C
A
A
A
C
C
C
A
I
I
agree
with
you
there
and
I
think
yeah.
It
is
I
mean
I,
have
like
five
PRS,
all
ready
for
this,
or
maybe
there's
six
in
in
various,
so
yeah.
It's
it's
a
multiple
step
process,
because
you
can't
make
this
change
in
one
tear,
obviously,
but
but
yeah
having.
We
should
add
that
to
a
cap
that
we
want
many
authorative
config
maps
instead
of
one
mana.
Let's
I
will.
A
The
initial
step
is
like
adding
support
for
multiple
config
files
being
loaded,
so
you
can
load
each
young
document
from
its
own
file,
which
means
you
can
have
or
you
can
like.
However,
you
want,
but
one
or
multiple
files,
or
maybe
a
director,
if
we
figure
out
how
to
do
that,
so
we
can
have
the
in
each
configuration
in
in
its
own
place,
which
is
way
better
than
then
now
like.
A
If
you
want
to
like
share
the
configuration,
but
still
like
have
some
master
specific
paints
or
whatever
it's
getting
really
tricky
with
this
design,
you
can
just
have
them
in
different
files
and
source
to
generate
config
from
one
plate,
one
file
and
master
specific
config
from
another,
so
it
takes
any
set
of
bytes
and
returns
a
map
between
group
version
kind.
This
is
a
struct
as
it
sounds
with
the
with
the
fields
group
version
and
kind,
along
with
the
with
the
young
document
itself
for
that
is
displayed
out.
So
here
we
create
a
buffer.
C
C
A
C
I
think
that
I
like
it
because
for
for
instance,
that
would
be
I,
guess
also
an
update,
configuration
and
up-to-date
configuration
and
the
updated
configuration
in
this
way
you
can
reuse
the
same
cluster
configuration
yeah
I.
Think
that
I
like
in
this
way
I
am
looking
at
the
I
theta
right
now,
but
something
interesting.
A
A
The
here
is
the
thing
when
we
don't
know
if,
given
if
we're
given
a
an
init
or
master
configuration
on
node
configuration
or
like
in
it
or
joint
configuration,
we're
just
going
to
read
it
we're
going
to
see
what
group
version
kinds
there
are
and
and
if
it
has
master
configuration,
it's
going
to
use
the
master,
configuration
specific
function
to
to
read
it
and
if
it
does
not
configuration
it's
going
to
use
a
node
specific
node
config
specific
function.
So
this
is
like
just
some
syntactic
sugar.
A
A
Other
than
that,
there's
not
much
that
so
these
cases
here
till
example
in
the
one
of
the
faces
commands
we
don't
know.
If
we're
given
a
must
or
a
node
configuration,
we
can
just
load
it.
We
have
it.
This
runtime
object,
which
is
the
common
interface
between
all
possible,
any
any
possible
kubernetes
api
object,
and
then
we
switch
on
the
type.
A
A
They
will
only
be
stored
here
inside
of
this
kind
of
helper
struct
in
before
they
were
in
their
own
kind
of
non-standard
structs
that
have
been
created
just
like
that.
So
when
the
conversion
code
from
version
1
alpha,
2
and
reading
a
version
1
of
a
to
file,
it
looked
like
this,
so
we
have
the
external.
We
have.
The
old
spec
transfer
the
information
from
here
to
here
now
in
the
internal
API
there
and
then,
when
converting
from
the
internal
API
to
version
1
off
a
tree
that
has
these
removed.
A
A
A
The
component
configs
are
only
stored
in
the
internal
API.
We
do
the
defaulting
in
set
in
its
dynamic
defaults,
as
we
do
with
other
other
stuff
as
well,
and
here's
the
large
change.
So
we
when
we're
on
marshalling
from
bytes
to
internal
we're
gonna,
we're
gonna
split
the
young
document.
First
first
text
part
version,
but
we're
gonna
split
the
document.
Now
we
have
a
map
of
the
group
version
kind
and
the
file
content.
A
If
we
find
a
component
config
that
we
recognize
from
the
kind
we're
going
to
decode
it,
we
have
a
set
of
codecs
here,
we're
going
to
decode
it
into
into
a
pointer
and
we're
gonna.
Well.
This
is
not
very
interesting,
but
just
to
raise
the
type
meta
information
from
there
for
the
unit
tests
and
if
it's,
if
we
find
a
master
configuration
kind,
we're
gonna
use
the
normal
flow.
A
Using
the
cube
idiom
scheme,
codecs
Marshall
into
internal
configuration
and
one
if,
if
it's
ignored
or
if
it's
kind,
we
don't
recognize
and
then
for
every
and
then
we're
going
to
apply
the
component
config
value,
we
just
loaded
to
the
internal
configuration
and
to
understand
fully
understand
this.
We
need
to
look
at
the
code
here
this.
This
will
change
a
bit.
It's
like
working
progress,
but
the
idea
is,
we
have
a
central
place
where
we
reduce
the
word
component.
Configs
we
support-
and
here
we
support,
for
example,
to
keep
proxy
configuration.
A
A
A
C
A
This
is
like
implementation
details,
but
as
I'm
not
I
mean
I'm
gonna
be
able
to
write,
these
ones
may
be
the
init
configuration
and
cluster
configuration
splits.
It
will
depends
on
how
fast
we
can
get
through
the
PRS
and
get
approval
and
and
like
how
much
time
I
have
this
week,
but
I'm
hoping
to
get
that
done
before
I
leave
as
well.
A
But
after
that,
so
that's
why
I'm
doing
the
knowledge
sharing
here,
because
we
know
need
to
know
while
stuff
is
ordering
the
way
it's
done
so
I'm
I'm,
seeing
erase
type
meta
to
go
away,
but
here
is
like,
and
this
I'm
also
thinking
this
will
go
away
cuz.
This
is
what
what
groups,
what
external
group
version
we
support
now?
Oh
no!
This
is
going
to
be
the
right
out.
Group
version.
I'm
gonna
clarify
that,
so
what
version
is
the
newest
one?
So
when
we
marshal
the
internal
config,
what
should
we
convert?
A
A
A
Here
we
create
a
scheme.
I'm
gonna
I'm
gonna
rework
this
bit,
but
we
need
to
create
a
scheme
first
in
order
to
support
loading.
Any
component,
config,
add
type
meter,
cube,
LM
schema
sexual,
not
needed
I'm,
going
to
remove
that
and
then
add
all
add
to
or
run
all
add
schema
functions.
So
we
so
I
can
know.
I
can
show
what
an
add
scheme
function
looks
like
this.
A
B
A
A
Using
the
specific
group
version,
so
this
means,
if
we
specify
an
external
group
version
here,
like
we're,
always
gonna,
do
like
version
1
beta
1,
its
first
gonna
convert
from
the
internal
API
to
the
external
API,
and
then
the
component
config
information
will
get
lost
and
then
write
out
the
bytes.
And
then
we
stole
the
bytes
here
in
a
byte
byte
array
and.
A
If
we,
if
we
converted
before
we
did
the
conversion
to
external
and
hence
lost
the
component
config
on
information
in
that
conversion,
we
should
write
them
out,
write
the
component
config
information
out
as
separate
documents.
So
that
is
happening
here
where
we
get
some
defaults
and
components
configs
or
we
get
a
defaulted
master
configuration
objects
that
is
created
like
this,
so
we
create
a
master
configuration
we
default
it,
we
convert
it.
The
internal
and
we
run
set
default
proxy
and
cublas
configuration.
A
A
And
when
we
have
that
we
can
we
compare
it
to
the
actual
component
config
we
have,
that
is
gonna
be
about
that
is
about
to
be
written
out,
and
a
weed
and
I
do
this,
because,
if
the,
if,
if
the
component
configuration
that
would
be
written
out
is
equal
to
the
default
configuration,
there
is
actually
no
need
of
writing
it
out,
and
it's
only
gonna
confuse
more
people.
If
they
see
a
lot
of
a
lot
of
knobs
when
it's
actually
not
native
I
am.
C
A
Yes,
it
does,
but
to
fake
to
fix
that
I'm,
just
gonna
I'm
planning
to
add
like
so
we
have
the
API
objects,
that's
a
P
objects
and
when
we
I'm
just
gonna,
let
that
be
so
the
default
list
there
is
master
configuration
and
node
configuration
right
and
I'm
just
going
to
extend
that
one
so
like
now,
we
support
also
queue
proxy
configuration
and
cubelet
configuration
and
the
list
defaults
to
all
four
so
that
when
marshalling
explicitly
the
master
configuration,
it's
gonna
be
only
the
master
configuration
yum
document,
but
we
use
a
default.
Api
objects
list.
C
A
C
Sorry,
if
this
will
change
the
top
people
from
the
pyaara
at
the
back
to
the
Kappa
yeah
I
mean
I,
think
kind
of
I
have
only
f2
lever,
so
I,
just
given
a
PSA
I
started
to
write
the
captor
at
the
beginning
of
the
documents.
So
if
you
or
anyone
can
give
a
check,
we
are
basically
copy
editing
the
cap
in
a
Google
document,
which
is
easier
for
the
first
pass.
Yes,.
B
C
A
Last
is
like
that
with
the
now
that
we
have
the
end
to
end
unit
tests,
we
can
clearly
see
what
the
internal
configuration
will
look
like
it's
pretty
much
the
same,
but
we
would
we
just
change
the
names
kind
of
I,
change
least
by
my
purpose-
to
see
that
so
then
non-default
so
when
we
convert
them
to
version
103
is
not
gonna.
Look
like
this
that
we
had
it
like
it,
Houston
embedding
both
Cuba
Thank
You
pro-q
proxy
conversion.
A
A
Thank
you.
If
there
aren't
any
questions,
I
think
this
walkthrough
is
kind
of
finished
and
we're
gonna
do
copy,
editing
and
more
work
on
the
cap.
Now
that
we
have
a
clear
path
forward,
I'm
also
gonna
have
to
bathe
the
or
resolve
the
comments
for
the
API
actual
API
proposed
API
structure,
but
that
is
another
topic
for
later
this.
This
was
more
how
to
do
drainage
hold
refactor
late.
Thank
you.
Bye,
bye,
bye,
bye
and.