►
From YouTube: 20191107 SIG Arch Community Meeting
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
A
B
So
the
main
thing
that
we
were
discussing
in
the
last
meeting
was
what
to
do
about
hypercube
the
plan
of
record
that
we
had
was
at
least
in
the
issue
this
as
discussed,
and
the
issue
was
okay.
We
don't
want
hypercube
in
KK
so
and
some
people
wanted
so
let's
move
it
out,
but
then
the
issue
there
was,
if
we
move
it
out,
we
will
vendor
kay-kay,
and
anybody
who
has
to
maintain
that
code
will
have
to
struggle
with
things
that
we
are
telling
the
community
not
to
do
which
is
render
KK.
B
So
then
we
said
and
it's
a
simple
go
file
and
all
it
does
is
use
everything
from
KK
so
and
it
is,
it
will
be
prone
to
breakage
and
if
you
know
it's
going
to
be
hard
for
people,
so
then
the
thing
we
also
said
was:
look.
We
have
to
move
people
off
of
the
hypercube
container
image.
So
how
do
we
do
that?
And
there
are
two
other
things
that
came
up
here.
One
was:
do
we
even
have
a
deprecation
policy
for
stopping
when
shipping
things
you
know
that
was
one
of
the
discussions
side.
B
B
B
Image
is
going
to
be
bigger
than
before
so
and
what
the
characteristic
here
is
that
we
would
like
people
to
move
off
of
the
single
hypercube
image,
so
we
are
giving
them
an
image
which
is
costlier
to
them
in
terms
of
size,
so
because
of
that
they
will
move
more
off
and
we
will,
over
a
period
of
time,
will
duplicate
this
image
and
stop
shipping
it.
So
that
was
the
plan
new
plan
that
we
came
up
with
and
the
P
are
actually
merged
this
morning
and
right
now
we
have
a
one.
C
Mike
Tanish
has
been
working
on
cleaning
out
a
few
dependencies
that
we
were
only
using
for
very
minimal
things
like
CF
SSL
and
a
couple.
You
would
library
things
like
that,
so
we're
trying
to
identify
dependencies
that
are
pulling
in
a
lot
of
other
things
that
we
are
only
using
for
a
very
minimal
number
of
features
and
see
if
we
can
collapse
under
standard
library
functions.
So
a
couple
of
those
went
in
this
week
so.
A
B
E
E
C
A
Don't
want
to
do
with
my
PBS
right
I'm,
just
saying
that
there's
a
you
were
saying:
there's
only
only
bringing
it
up
because
Jordan
said
hey
what
are
things
that
have
minimal
dependencies
and
I
only
discovered
this,
because
we
wanted
to
update
some
dependency
right
and
I
tracked
it
down.
I'm
like
this.
This
Lib
network
is
used
in
like
this
one
narrow
place
and
that's
it,
and
yet
it's
pulling
in
this
whole
list
of
dependencies
right.
F
C
C
That
right,
yeah,
that's
an
excellent
candidate
for
like
a
debt
code
organization
issue,
the
people
who
pulled
in
the
code,
for
that
might
not
even
be
aware
of
the
gridlock
it's
causing,
and
so
it's
at
least
worth
an
issue
to
surface
that
and
say:
hey!
Is
there
a
way
we
can
pull
out
this
one
function
or
do
this
differently,
because
it's
causing
pain
for
the
whole
project,
yeah.
C
F
Yeah
I've
seen
some
like
lightweight,
lighter
weights
that
link
handles
or
IPs
that
might
be
worth
looking
into.
I
can
follow.
B
Removing
the
entry
OpenStack
cloud
provider
I
have
a
PR
ready.
The
PR
was
originally
logged
October
last
year
and
I've
been
revising
it
periodically,
and
the
latest
revision
is
ready.
I'll
get
an
okay
from
the
OpenStack
folks
and
then
we
will
check
with
the
CSI
migration
stuff
and
then
we'll
figure
out.
If
we
can
merge
that
before
next
week
as
well,.
F
Sure
yeah,
we
were
talking
about
some
of
the
pain
points
with
future
branches
because
it
requires
giving
folks
working
on
the
branch
higher
privileged
access
to
the
kubernetes
repo,
until
jordan
recommended,
if
folks
can
just
create
their
own
personal
Forks
and
then
just
grant
access
to
the
teams
that
are
working
on
that
and
then
it
would
effectively
give
people
throw
a
future
Forks.
The
biggest
downside
to
that
is
we
lose
history
of
the
fork.
F
C
Be
clear:
this
was
kind
of
an
experiment.
We've
tried
a
few
feature
branches
in
the
repo
in
the
kubernetes,
repo,
two
or
three
I.
Think
and
this
the
ingress
folks
were
wanting
to
try
to
get
a
feature
branch
started,
and
so
this
is
kind
of
an
experiment.
It
seems
like
it
was
a
good
fit.
They
have
maybe
two
or
three
people
collaborating
on
it
and
the
end
result
is
a
series
of
commits
in
a
regular
pr2,
kubernetes
kubernetes.
So
you
don't
lose
commit
history
or
anything
like
that.
C
If
this
works
well,
we
might
look
into
having
an
org.
That
is
not
really
a
privilege
to
work.
It's
just
one
where
we
could
archive
archive
repos
to
preserve
history
under
the
org,
but
you
would
view
a
normal,
create
a
branch
hoping
to
pull
request
to
kubernetes
communities
and
all
the
CI
stuff
would
work
normally
there.
So
this
is
still
kind
of
experimental,
but
it's
pretty
lightweight
and
we'll
see
how
it
goes.
B
A
Production
readiness
review,
so
we
met
yesterday
for
the
third
time,
I,
guess
and
we're
moving
along.
We
are
working
on
folks
reviewing
the
questionnaire
as
it
is
today
we're
working
on
coming
up
with
some
field
research
around
previous
you
know
both
of
Google.
The
idea
is
to
come
up
with
both
the
Google
Form
and
also
a
sort
of
more
in-depth
interview
for
one-on-one
interviews
and
we'll
send
that
out
and
broadly
as
we
can
to
try
and
solicit
you
know,
or
our
stories
and
other
and
other
kinds
of
production
issues.
A
People
have
had
to
make
sure
that
we're
making
asking
the
right
questions
and,
at
the
same
time,
we've
picked
out
a
handful
of
caps
that
were
going
through
with
the
authors
to
answer
the
questions
as
we
have
them
today
and
try
and
see
how
effective
that
is.
So.
Nothing
super
exciting
to
report
we're
just
moving
along
with
kind
of
the
pilot
phase
of
this.
A
G
Sure
I
can
speak
to
that.
So
myself,
Alessandro
and
Dems
have
been
working
on
this.
We
probably
met
like
three
times
now
and
kind
of
trying
to
define
what
this
means,
what
we
want
to
do
and
what
are
the
try
aging?
What
are
the
ways
we
can
find
a
tech
debt
or
something
that
feels
like
a
tech
debt,
and
then
we
have
a
project
on
board
project
ongoing
that
has
an
incoming
where
we
can
flag
issues
as
possibly
debt
debt.
G
Can
someone
click
on
that
dock
link
or
yeah,
so,
basically
me,
and
unless
Andrew
and
dim
have
like
we're,
still
collaborating
on
this
job.
This
is
basically
a
rough
draft
of
what
we
think
we
want
to
do
and
how
we
want
to
do
it.
So
essentially,
we
want
to
find
out
what
tech
that
is
and
how
we
can
identify
it
quickly
and
then
bring
those
tended
to
to
attention
to
this
sake
and
I
mean
possibly
find
a
paved
path
to
trigger
some
of
these
findings
into
the
signal
he's
planning
right.
So
this
is
here.
G
This
is
basically
an
attempt
to
define
what
our
sector
take
that
it
John.
Can
you
go
to
what
the
tech
that
is
yeah
the
feature?
It
was
our
tech
debt.
So
basically
we
are
saying
that
we
can
distinguish
take
that
from
feature
request
by
causing
the
quality
of
the
change
and
that
would
be
required
and
then
the
recurring
cost
it
will
eliminate
right.
G
I
think
that
last
part
is
the
key
part
I
feel
like
if
we
can
find
issue
scaps
or
PRS,
that
that
basically
help
eliminate
some
kind
of
recurring
cost,
whether
that
recurring
cost
is
in
areas
of
maintainability
usability
d,
possibility,
adoption
right
and
I
think
the
key
point
is:
how
do
we
identify
those
issues
so
John?
Can
you
scroll
one
more
time
so
I?
Basically
anything,
we
are
basically
looking
for
these
factors
in
18
things
and
finding
out.
G
H
G
So
I
think
I
mean
a
lot
of
adoption
also
helps
improves
the
credibility
as
well
as
brings
more
people
to
support
it
and
it
watches
for
for
what
direction
those
things
are
heading
right,
so
I
think
in
that
sense
it
it
helps
but
yeah
it's
not
clear,
so
I
can
make
that
more
clear
in
the
doc.
Does
that
make
sense.
G
Me,
yes,
yes,
I,
think,
that's
a
very
accurate
description.
Anything
that
is
that
improves
the
adoption
is
what
we
want
to
tackle
as
well,
so
so
that
is
in
one
sense,
technical
debt,
and
then
there
are
other
things
like
I.
Think
one
of
the
things
I
have
seen
in
issues
is
like
people
had
so
much
pain
that
Bay
they
actually
worked
around
it
by
creating
an
operator
like
thing
not
essentially
an
operator,
but
basically
a
workaround
for
it.
I
mean
I,
know
that
we
have
layering.
G
Where
basically
we
say
this
is
where
the
kubernetes
boundaries
and
and
something
needs
to
be
an
operator
but
but
I
have
an
example
of
where
somebody
found
out
that
they
were
not
able
to
find
whether
a
container
was
killed
because
of
an
event
or
not.
So
have
an
example
where
somebody
basically
created
a
something
that
that
observes
four
things
in
different
areas
of
the
container,
skaters
and
conditions
and
finally
flags-
and
even
that
says,
oh,
this
event
was
basically
killed
and
this
is
continuously
been
basically
killed
by
an
event.
G
So
that's
basically
an
example
of
an
area
and
debug
ability
where
people
felt
the
pain,
and
there
was
an
issue
with
multiple
people
commented
on
it
saying
we.
We
should
have
that
as
an
event
or
something
that
clearly
shows
why
this
container
started,
but
the
actual
reason
for
that
container
restart
work,
oh
and
kick
om
killed.
Even
that
is
like
deep
beneath
in
some
logs
or
something
so.
H
G
I
think
that's
a
great
point,
I
mean.
Basically,
there
will
always
be
cases
like
that,
where
we
will
have
to
figure
out
whether
that's
a
deliberate
attempt
from
the
kubernetes
core
group
to
say
that
that's
something
that
we
don't
want
to
flag
and
it
should
be
built
as
an
upper
layer
versus
things
that
should
belong
in
this.
So
we
need
to
find
a
way
to
figure
that
out
right.
B
B
We're
gonna
shine,
light
on
things
that
are
languishing
and
or
not
being
worked
on
or
where
people
are
asking
for
stuff,
like
the
other
example
is,
for
example,
the
our
limit
one
or
you
know
the
namespace
deletion
was-
was
a
hard
problem
for
a
while
until
we
did
a
bunch
of
things
about
it
right.
So
there
are
several
examples
from
the
past
where
we
can
say
that
oh
I
wish
we
could
have
fixed
it
earlier
or
you
know
people
were
getting
stressed
about.
Why
is
my
name
space
not
getting
deleted?
G
So
you
have
identified
some
broad
categories
and
made
columns
in
the
project
board,
so
I
mean
I.
Think
the
main
thing
we
want
to
tackle
is
come
up
with
some
criteria
that
we
all
agree
on,
that
we
can
publish
in
this
dog
so
that
people
or
community
or
users
have
a
clear
way
of
flagging
them
to
this
group
of
people
right
and
then
it
is
for
us
to
basically
say
that
that
is
indeed
a
Techdirt
that
should
be
prior
left
prioritized
for
security.
B
And
this
will
be
like
a
pool
of
things
that
are
there
for
the
six
to
go,
look
at
and
say:
okay,
maybe
we
should
prioritize
one
of
this
or
two
of
this.
The
cycle,
and
you
know
and
pick
something
that
is,
you
know,
there's
always
trade
off.
How
much
time
it's
going
to
take
versus.
Is
it
do
we
are
we
really
gonna
fix
it?
If
we
are,
if
we
know
that
we
are
gonna
fix,
it
then
make
sure
that
there
is
enough
description
in
there
so
that
next
time
somebody
says
I
need
this.
B
You
know
they
don't
they'll,
read
that
thing
and
say:
okay,
fine!
They
already
decided
they're
not
going
to
do
this
right,
so
a
dispensation
one
way
or
another,
whether
we
decide
not
to
do
it
or
you
know-
maybe
we'll
do
it
later,
but
then
it's
up
to
the
actual
cig
or
a
group
of
six
to
you
know
rule
on
that.
This.
The
role
of
this
group
is
just
to
build
the
way
I
we
were
feeling
about.
B
This
was
there's
a
bunch
of
things
that
that
we
are
not
looking
at
like
a
code
organization
is
not
looking
at
this.
You
know.
Cig
testing
is
not
looking
at
this.
You
know,
there's
nobody
who's.
Looking
at
this
class
of
problems
where
people
are
asking
for
things
and
we
are
not
giving
them
guidance,
whether
we
will
do
it
and
whether
we
will
prioritize
it,
and
so
that's
that's
the
reason
for
trying
to
come
up
with
this.
Okay.
C
That
to
me,
that
is
not
a
technical
that
category.
That's
a
usability
category
or
you
know
new
user
experience.
Type
of
category
like
it
may
be.
This
is
just
a
way
of
referring
to
technique
that
I've
never
heard
before,
but
like
in
my
experience,
tech.
That
is
the
kind
of
thing
where
you
took
shortcuts
to
do
a
thing
and
you
never
went
back
and
cleaned
up
the
shortcuts
and
that
the
evidence
of
that
is
that
something
is
like
internally
more
complex
or
doesn't
handle
edge
cases
or
is
difficult
to
add
new
things.
D
G
The
I
mostly
agree,
I
think
the
main
thing
is
like
when
we
say
we
if
we
are
trying
to
fix
something
that
improves
usable,
that
the
the
the
recurring
cost
that
it
is
reduce
that
it
is
improving,
is
basically
the
recurring
cost
of
we
all
going
through
all
these
issues
and
replying
to
this,
because
the
usability
is
not
good
or
because
we
are
trying
to
reply
it
on
the
discussion
mailing
list
that
this
needs
to
be
done.
This
way.
No,
you
got
it
totally
wrong,
because
this
is
not
what
we
intended
to
do
right.
G
A
Sorry
I
would
agree
that
there's
costs
there,
but
I
think
we.
We
already
have
pressure
to
build
features.
We
already
have
practice
pressure
to
improve
things
that
users
want
and
to
me,
I'm
more
lined
up
with
what
Jordan
say
year
that
the
tech
debt
are
things
that
we
did,
that
we
hid
and
in
fact
I
would
think
the
best
way
to
discover
those
one
yeah.
A
You
can
go
through
issues,
but
actually
the
best
way
is
going
to
be
to
identify
a
list
of
a
dozen
people
who
know
all
of
that
tech
debt
in
their
heads
because
they
they
wrote
it.
You
know
four
years
ago,
whatever
it
is
five
years
ago,
three
years
ago
and
and
they'll
tell
you,
because
it's
probably
they're
burning
to
fix
it.
They
just
don't
have
to
write.
So
maybe
most
people
maybe
have
already
created
issues,
and
so
maybe
you
know
just
be
rediscovered
things,
but
you'll
get
a
good
sense.
A
If
you,
if
you
identify
those
people
and
just
talk
to
them,
they'll
have
a
list
in
their
head
of
three
or
four
or
five
six
things
that
they
think
should
be
fixed,
and
so
those
have
hidden
costs
that
users
don't
see
EBIT.
It
means
you
know,
like
Jordan
I,
think
said
you
know
now
we
can't
add
this
other
feature,
because
it
would
have
pointed
us
to
go
back
and
rip
out
all
this
stuff
or
you
know
we
like
it.
It
causes
reliability
issues
because
the
edge
cases
aren't
all
covered
and
etc,
etc.
A
So
I
think
that
that
both
of
those
are
noble
efforts,
but
if
we're
gonna
have
a
tech
I've
heard
I
would
prefer
it
focus
on
things
that
aren't
necessarily
things
users
are
pushing
for,
because
we
already
have
enough
pressure
for
that
and
who's
sort
of
representing
the
the
the
other
issues
that
are
more
hidden
from
users
would
be.
My
question.
C
Yeah,
the
the
one,
maybe
the
one
exception
of
that,
like
long
lived
bugs
that
are
recognized
as
legitimate
bugs
that
have
a
lot
of
user
attention.
That
seems
like
something
that
Maps
detected
really
well
like.
This
is
a
recognized
bug
that
the
people
running
the
project
agree
is
a
bug:
it's
not
a
desired
behavior
or
designed
behavior
and
it's
old,
so
it
hasn't
gotten
attention
and
it's
popular
like
you
know
your
thumbs
up
or
lots
of
comments
or
lots
of
me
too.
This
has
bit
me
that
seems
like
legitimate
technical
type.
C
Kind
feature
or
a
user
reported
bug
like
if
the
user
reports
a
bug,
but
it
actually
is
an
intentional
design.
Behavior
like
that,
could
if
we're
seeing
those
over
and
over
that
probably
means
our
documentation,
is
bad
or
like
something
about
the
discoverability
of
the
decision
is
bad
but
I,
don't
I'm
trying
to
avoid
this
becoming
like
another
way
to
get
a
feature
request
into
a
prioritized
queue.
D
C
Nothing
for
this,
like
I,
think
there
are
other
contexts
where
that
makes
sense
like
we
know,
sig
is
deciding
what
to
do
or
the
sig
usability
I
think
falls
more
under
their
their
mission.
I
guess
kind
of
look
at
what's
painful
for
users,
regardless
of
whether
it
was
intentional
or
not.
How
can
we
reduce
that
pain
with
documentation
or
examples
of
features
or
whatever
and.