►
From YouTube: 20200625 SIG Arch Code Org
Description
GMT20200625 180334 SIG Archit 1600x778
A
A
So
the
first
one
is
a
new
er
from
in
Jan
and
Jan
I.
Think
John
chalupa,
sorry,
I,
don't
know
how
to
pronounce
this
name.
Let
me
just
get
it
right:
shallow
columnar,
I
think,
okay.
So
what
he
is
proposing
here
is
having
a
stage
repository,
but
then
the
twist
here
also
is
six
scheduler
shows
up
in
the
pot
and
like
piston
to
go
down
the
route
for
this
pattern.
Jordan.
What
do
you
think.
A
B
B
So
we
had
a
need
for
moving
the
are
back
role:
reconciliation,
stuff
out
of
kids,
I/o
kubernetes,
so
that
kid
control
can
complete
its
move
out
of
tree
scheduling,
had
a
similar
need
for
a
place
where
the
scheduler,
in
the
controller
and
during
the
API
server
could
share
these
helper
methods
that
build
on
top
of
external
API
types,
and
so
the
question
was
like
how?
Finally
do
we
slice
components?
Like
you
have
a
scheduling,
library
component?
You
have
an
authentication
library
component.
B
You
have
just
a
things
that
build
helpers
on
top
of
API
types,
library,
I
I.
Don't
have
super
strong
feelings
about
how?
Finally,
we
slice
it
I
know
the
more
we
have
the
harder
it
is
to
manage,
though
I
I
don't
think
we
want
like
one
for
every
package
like
here's,
the
are
back
module
and
the
scheduling
module
and
the
a
back
module
and
the
God
seems
to
fine
David
had
proposed
this
level
of
granularity
and
it,
it
generally
seems
like
it
could
work.
B
A
A
B
B
A
B
A
A
And
so
just
in
terms
of
mechanics,
this
would
be
a
single
repo
that
will
be
across
six
right
so
but
then
scheduler
might
be
the
first
one
to
get
in.
So
there
is
a
bunch
of
mechanisms
that
we
need
to
do
to
get
a
staging
repository
in
place
right
so
including
requesting
you
know
a
github
repository
for
for
the
stage
repo,
then
updating
the
publishing
bought
and
there's
like
a
ton
of
things
to
do
so.
I
think
we
need
this.
B
A
B
A
B
Cases
like
we
have
two
or
three
examples:
okay
and
I
think
that's
probably
enough
to
get
started
and
to
take
to
cigar
ch
to
say,
like
here's,
what
we'd
like
to
do
and
why
and
your
the
cigs
that
are
interested
so
far,
okay
kind
of
like
it's
easier
to
start
and
try
out
two
or
three
things,
and
then,
if
we
see
issues
like
make
adjustments
instead
of
getting
like
thirty
things
and
then
having
to
go
fix
thirty
things.
If
we
decide
we
wanted.
A
B
C
A
A
D
Not
especially
I
mean
I
wanted
you're,
both
aware,
but
I
have
the
graph
to
help
understand
of
the
graph
to
help
understand
the
the
layout
and
what
need
sort
of
what
our
layering
model
currently
looks
like,
so
that
we
don't
introduce
cycles
and
things
like
that.
Help
us
sort
of
come
up
with
what
the
layering
should
be,
what
it
is,
and
maybe
what
it
should
be.
A
D
You
I'm
not
I
mean
I
I.
Certainly
there
were
a
few
things
that
are
surprising.
None
of
them
are
coming
to
mind
right
now,
but
they're.
Certainly
there
were
things
that
were
at
different
depths
in
this
tree
than
I
was
expecting
I'm,
not
sure
that's
wrong,
but
I
I
definitely
found
one
or
two
of
the
items.
A
little
surprising.
A
D
Yeah
I
would
love
to
work
out
a
nicer
way
of
building
this
I
mean.
Certainly,
there
were
a
few
of
the
items
in
the
rather
than
in
the
staging
only
but
in
the
one
that
includes
some
of
the
externals,
where
I
was
a
little
surprised
that
there
were
a
couple
of
dependencies
like
you,
Dalls,
which
we
depend
on
a
bunch
of
it
from
staging,
but
it
also
depends
on
a
bunch
of
things
from
staging.
No,
that's
not
true.
D
D
D
D
A
D
C
A
C
A
B
D
A
E
A
A
D
A
D
I'm
staying
in
touch
with
Saad
and
Michelle
on
the
CSI
stuff.
I
know
that
on
the
cloud
provider
GCP
repo,
we
are
hoping
that
in
the
next
quarter
we
will
actually
prove
the
CSI
stuff
work,
so
I'm,
coordinating
with
Michelle
and
Scott
about
showing
them
that
the
CSI
can
actually
be
used
to
get
a
cloud
provider
free
volume
handling
and
then,
after
that,
I
think
the
Omni
see
it
on
the
cloud
provider
extraction.
The
slowest
the
longest
pole
we
have
is.
D
A
D
So
I
this
is
why
I
called
it
a
prototype
rather
than
an
alpha
right,
even
if
we
can't
get
it
into
119,
if
we
can
at
least
show
a
functional
like
a
functional
implementation
of
the
cap,
I'd
be
pretty
happy,
but
I'm,
not
even
sure
we're
gonna
get
that,
and
then
that
makes
me
worried
whether
or
not
we
have.
We
can
have
something
ready
for
120.
D
No
I
mean
and
come
bug
me
I
mean
it's
it's
something
nice
big,
we
wear
it.
I
Pro
the
working
group
in
a
sig
I'm
part
of-
and
this
is
our
long
pole
on
both
so
I-
do
not
object
to
you
chasing
but
I'll.
Let
you
know
like
I'm
I
am
closely
tracking,
where
we
are
with
this,
because
it
is
our
longest
all
right.
A
E
B
A
A
A
B
A
A
A
So
it's
not
exactly
the
same
list
of
files
that
they
all
operate
on.
So
that
was
the
other
problem
that
I
notice
and
we
might,
we
could
change.
Golang
ci
is
really
nice.
I
have
seen
it
used
and
several
other
projects,
but
it's
just
going
to
be
a
big
effort
to
get
there
and
I.
Don't
know
how
much
useful
it
is
to
do
that
work,
yeah,
I
would.
B
A
B
B
D
A
A
But
the
other
way,
also
to
look
at
this
Walter
is
maybe
that
is
the
right
place
to
keep
it
and
use
it
from
there,
and
we
would
basically
for
when
we
are
testing
KK.
We
would
say
we
need
an
additional
repository
injected
and
we
would
basically
kick
off
the
cluster
Cuba
script
from
that
repository
instead
of
the
one
in
the
main
repository
and
basically
new,
the
one
that
we
have
in
KK.
Oh,
you
know
once.
D
We
get
what's
been
that
I
mean
I.
I
would
suggest
that
eventually
it's
not
kubernetes
responsibility
to
do
the
GCP
testing.
That's
cloud
providers,
ECP's
responsibility,
and
so
some
of
that
can
should
just
go
away
from
anything.
Kk
has
to
worry
about.
It
does
leave
us
with
scalability
needing
an
answer
to
where
they
do
their
scalability
testing,
but
right.