►
From YouTube: 20200227 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
A
B
C
C
The
update
is
on
velocity
and
our
velocity
has
been
pretty
poor
for
the
up
for
the
first
quarter
first
half
of
last
year,
but
we've
had
a
lot
of
help
through
air
and
other
folks
to
just
really
simplify
and
clarify
the
work
flow,
and
that's
resulted
in
consistent
velocity
increases
for
a
good
long
while
and
I
think
that
will
increase
a
key
part
of
that
is
the
triage
process
that
we
do
during
our
our
meetings,
creating
mock
test
tickets
and
those
flowing
into
before
we
start
doing
tests
PRS
and
promotions.
It's
helped
a
lot
and.
C
If
we
go
look
at
the
data,
we're
soon
gonna
replace
the
main
API
snoop
site
with
this
data
that
comes
from
our
buckets
I'll
drop
this
link
into
our
our
chat.
It's
just
API,
so
hh-hi
coop-
and
this
is
approximately
the
last
year
and
if
you
go
into
these
data
points,
they'll
take
you
to
the
buckets
related
to
that
data
over.
C
2019
we
saw
a
velocity
increase
of
300%
and,
in
the
second
half
Aaron,
helped
to
curate
much
of
the
cultural
process
that
contributed
that
helping
us
get
the
needle
movie,
because
it
was
quite
stuck
the
reason
that
those
numbers
come
from
the
first
half
of
the
year.
We
got
about
2%
of
an
increase
in
his
second
half
of
the
year.
We
got
around
7%,
so
this
was
the
summary
for
last
year
and
I
think
that's
positive
and
I.
Like
those
numbers,
I'm
learning
a
bit
about
objectives
and
key
results.
C
I
know
there
are
a
few
companies
that
use
that
and
a
few
culture
so
I
figured.
It
might
be
easy
just
to
say
what
our
q1
objectives
were,
at
least
in
general
interests,
the
conformance
subgroup
and
I'd
love
to
see
and
I
think
we're
I'm
feeling
pretty
orange
about
it
as
of
yesterday.
So
I'm
not
I'm,
not
fully
green,
but
it's
okay.
It's
time
to
stretch.
Can
we
get
a
hundred
percent
increase
over
what
we
had
in
the
second
half
of
2019
our
overall
and
the
result
to
measure
that
did
we
get?
C
C
Here's,
the
underlying
stuff,
that's
in
the
pipeline.
These
are
the
things
we
talk
about
on.
All
of
our
performance
project
meetings
is
moving
it
up
to
the
conformance
test
percentage
points,
so
we
are
currently
at
around
2.2,
and
these
are
the
10
points
that
are
in
already
either
merged
or
are
waiting
for
approval.
C
C
We
have
a
sorted
backlog
and
all
of
this
backlog
has
been
reviewed
for
the
mock
test.
That
says,
is
this
endpoint?
Something
we
want
to
have
in
conformance.
Is
this
the
right
documentation?
Is
this
mock
test
that
we've
written
exercise?
It
correctly
so
we're
pre
validating
all
the
work
and
that
workflow
has
led
to
a
really
good
increase.
The
older
way
we
did
stuff
is
hard,
and
so
we've
got
a
few
of
those
stragglers
cleaning
up
but
I'm,
hoping
that
those
PRS
will
either
merge
or
we'll
be
finished
with
them
soon.
C
We
tend
to
throw
push
to
master
and
things,
and
so
we
want
to
move
more
towards
the
get
flow
adopted
by
the
communities
community
and
then
finally,
there's
a
few
non
prowl
pieces
that
I've
been
using
our
you
know:
I
eyes,
Google
Google
project
and
I,
send
a
bell
and
we'd
like
to
left
to
use
the
infrastructure
provided
by
the
CN
CF
members
either,
and
we're
doing
a
lot
of
that
with
prowl
for
Google
and
there's
also
a
few
pieces
of
eks.
That
will
be
moving
onto
that
way.
I'm
not
saying
there's
no
other
bills.
C
C
Our
last
thing
for
q1
is
trying
to
mentor
and
teach
some
test.
Writing
workflow
and
we'll
be
doing
some
of
that
at
koukaon
g.
You
pretty
much
we're
gonna
take
some
of
the
flow
we've
been
doing
and
do
some
mentoring
there
at
at
KU.
Con
and
I've
lined
some
of
that.
Some
of
that
up,
it's
becoming
a
lot
more
polished,
starting
from
just
having
docker
and
running
a
few
commands
to
getting
in
cluster
development
that
creates
our
mock
tests
and
our
workflows
that
result
in
what
gets
validated
by
the
conformance
meetings
every
other
week.
C
This
may
change
based
on
conversations
we
have
of
this
meeting
and
the
work
that
John
and
his
team
have
got
as
far
as
the
behaviors.
But
this
is
what
we
have
in
some
time:
I'm
moving
toward
those
goals.
Do
you
think
we
should
also
be
gaining
kkp
RS,
that
touch
API
to
tests
and
come
and
how
we
measure
that
is,
will
be
common
thing.
The
actual
list
of
increasing
decrease
endpoints.
So
anything
that
touches
swagger
I
think
we
can
do
it
for
alpha
beta
and
stable.
C
So
this
is
the
PR
that
added
these
particular
end
points.
These
got
removed
from
stable
and
moved
over
to
the
beta,
and
we
can
do
that's
just
comments,
also
separately,
commenting
with
the
list
of
increase
and
decreased
conformance
in
points.
So
these
are
the
new
conformance.
End
points
well
also
comment
within
points
if
they
disappear
for
some
plumbing
reason
and
will
block
on
those.
So
we
can't
drop
the
list
of
end
points.
C
There
was
interest
in
q4
and
q1,
but
the
number
was
the
number
drop
was
minimal
and
we
call
those
manually.
It's
had
less
priority
because
I
was
focused
on
velocity
and
the
team
was
focused
on
velocity
and
we'll
also
look
at
gating
Kate's
Kate's
performance,
barricades,
CNC
up
gates,
conformance
PRS
for
people
submit
their
conformance
results.
C
The
gating
there
will
be
commenting
with
a
list
of
unrung
conformance
tests.
We've
had
some
number
mismatches
where,
depending
on
how
they
ran
the
test,
they
ran
a
different
number
of
tests,
possibly
different
tests,
and
we
need
to
know
that
we
know
that
we
know
that
they
passed
this
precise
list
of
tests
in
an
automated
one-off
and
possibly
if
there's
interest
in
the
workflow
like
we
go
and
we
mentor
in
Amsterdam,
maybe
there'll
be
some
folks
interested
in
doing
this
beyond
beyond
the
AIA
and
conformance
team.
C
In
summary,
prior
at
the
q3
I
think
I
didn't
quite
finish,
the
summary,
but
prior
to
q3
19
glossy
was
a
great
second
half
it
increased
and
then
q1
we're
doing
the
whole
lot.
You
know
and
then
it's
going
to
get
better.
So
in
general,
this
is
the
the
roll
up
and
status
for
the
conformance
sub
project
and
I'll
turn
it
back
over
to.
E
E
F
C
F
C
C
G
I
wanted
to
call
out
a
few
categories
of
work
that
has
been
going
on
over
the
past
couple
weeks.
The
first
category
is
issues
that
have
come
up
that
are
under
active
discussion,
so
I
linked
out
twos
for
the
relevant
issues
or
PRS.
If
you
are
interested,
but
these
are
bringing
up
edge
cases
in
some
of
the
documentation
and
approaches
that
we've
had
around
evolving
api's
and
there's
a
lot
of
discussion
in
some
of
these.
G
The
third
one
is
an
overall
one,
so
these
are
the
first
couple
are
cases
where
we
either
added
a
new
field
and
had
sort
of
special
fancy
rules
around
defaulting
and
the
mutability,
and
a
lot
of
questions
about
what
could
happen
in
those
cases.
My
goal
is
to
once
we
resolve
these
specific
questions
to
clarify
like
what
our
overall
approach
should
be
like
what.
G
How
did
we
get
into
this
situation
for
these,
and
what
do
we
need
to
be
clearer
about
or
stricter
about
or
do
differently
to
avoid,
hitting
this
type
of
thing
again,
so,
if
you're
interested
the
first,
the
first
one,
especially
it's
a
very,
very,
very
long
thread,
we
might
bring
github
eventually
on
this
one.
Maybe.
H
H
H
G
I'm
not
sure
we
got
it
wrong,
I
think
I,
think
the
thing
we
didn't
consider
was
old.
Clients
only
know
about
the
old
field,
and
so
the
old
field
should
always
always
always
Trump
like
that.
We
had
other
cases,
I,
think
service
account
and
service
account
name
are
similar
where
the
old
field
always
takes
precedence
and
new
clients
are
expected
to
set
both
yeah.
H
B
H
I
G
I
G
I
G
Can
be,
but
there
are
a
few
really
particular
types
of
changes
that
I
think
would
be
high-value
and
relatively
low
effort,
so
we're
not
to
solve
them
all
at
once,
but
if
we
have
a
couple
or
three
different
flows
that
are
the
types
of
changes
that
people
make
the
most,
that
would
be
a
great
starting
place.
Yeah.
G
The
third
item
I
like
to
this
is
a
quick
doc.
I
wrote
up,
we
immutability,
we
have
immutable
fields
in
several
places
and
API
and
then
there's
a
proposal
to
add
or
add
the
capability
for
them
to
custom
resources,
and
we
don't
have
a
great
like
a
very
principled
approach
to
how
that
should
interact
with
declarative
reconciliation
tools.
I
I
think
I
think
this
is
actually
a
good
thing
for
us
to
talk
about-
maybe
not
in
this
meeting
but
as
a
whole
project
right
now,
because
the
server
side
of
my
code
is
going
Universal
of
this
release,
which
means
we
can
begin
to
put
schema,
checking
things.
It's
like
a
central
check
point
for
this
sort
of
thing.
So
this
is.
This
is
now
a
great
time
for
us
to
figure
this
out
to
the
point
of
immutability.
H
I
Let's,
let's
pair
that
with,
we
need
some
sort
of
ratcheting
concept
so
that
we
can
tighten
validation
over
time
just
because
server-side
apply
holds
up
cases
where
validation
hasn't
been
correct,
like
you
can
have
to
environment
variables
in
a
pot
with
the
same
name
and
that
breaks
everything.
We
don't
eat
everything
if
you
send
a
strategic
patch
removing
one
of
them.
It
removes
both
yeah.
I
I
I
Exactly
anyway,
if
we're
going
to
be
more
strict
and
more
consistent
about
enforcing
our
schema,
we
need
a
way
to
bring
existing
non-conforming
objects
up
to
par
without
breaking
people,
so
that
that's
ratcheting
immutability
in
particular
is
interesting
and
more
complicated
than
one
would
expect
at
first,
because,
as
Stefan
has
pointed
out,
and
some
of
his
proposals
for
C
or
DS
like
there's
separate
concepts
about
like
I
feel,
could
be
immutable.
What
does
an
import
container
to
be
immutable?
Is
it
okay
to
have
the
keys
mutable,
but
not
the
content,
not
the
values
like?
I
A
I
I
G
So
I
think
Tim.
You
made
a
comment
and
the
in
that
link
to
dock
that,
like
sometimes
in
you
know,
ability
is
what
you
want,
because
it
Maps
well
to
something
that
is
represented
by
the
underlying
some
underlying
resource,
and
so
you
actually
can't
change
this
thing
and
so
I
delete
and
create
a
different
one
models.
H
H
Adding
an
immutable
feel
violates
that
just
like
adding
a
required
field
violates
that
and
I
feel
a
lot
of
empathy
here,
because
there
are
times
when
the
cost
of
implementing
a
logically
immutable
field,
as
mutable
is
really
steep
steeper
than
is
worth
paying,
but
from
an
api
compatibility
point
of
view.
Either
we
decide
we're
going
to
allow
those
sorts
of
breakages
or
we
say
we're
not
in
which
case
a
beautiful
fields
are
not
allowed.
When
you
add
them
just
like
or.
H
Turns
every
put
into
a
patch,
but
every
put
is
a
patch
today
like
this
is
the
classic
rest.
Nobody
has
ever
implemented
patched
the
explicit
way
because
it
doesn't
actually
provide
any
value
for
end-users
unless
you're
completely
objective
and
that
ships
sailed
a
long
time
ago.
Our
puts
didn't
find
in
our
logic,
any
place
that
actually
tries
to
turn
a
butt
into
a
patch.
By
masking
we
don't
have
microwave
diapers,
and
so
I
can't
tell
whether
you
tried
to
unset
a
field
or
whether
you
just
didn't
know
yeah.
G
G
Maybe
more,
there
is
the
implications
for
new
types
like
what
is
our?
What
is
our
recommendation
going
forward?
Should
we
really
try
not
to
add
a
mutable
fields
if
possible,
like
I?
Think
a
mutable
fields
have
been
sort
of
an
easy
button
because
it
lets
you
not
worry
about
reconciliation
and
kind
of
skip
a
whole
category
of
you
know
consistency
issues,
but
we
see
problems
with
them
in
like
staple
set
volume
claim
templates
like
if,
like
we
have,
the
ability
to
request
a
volume,
be
increased
in
size.
G
But
if
you
use
the
stateful
set
to
drive
it,
you
can't
you
can't
do
that.
A
mistake
will
set
you
good.
You
still
allow
changing
selectors
on
workload
templates
and
we
defaulted
those
selectors
to
match
the
labels
of
the
template,
and
so,
if
someone
put
a
version
label
in
their
pod
labels-
and
that
has
been
happily
ticking
along
updating,
you
know
every
time
they
update
their
workload
and
then
suddenly
in
1/16.
Those
are
immutable
and
apps
v1,
and
now
they
can't
update
their
workload
anymore.
Do.
H
We
have
any
mechanism
for
moving
from
immutable
to
mutable.
Like
Clayton
I
know,
we've
been
on
a
bunch
of
API
reviews
where
we've
told
people,
unless
you
know
you
need
to
update
this
field,
just
don't
allow
it
yeah
and
like
pod,
is
a
great
example
of
that.
Where
I'd
say
pod,
being
immutable
has
helped
us
from
a
pragmatic
perspective,
evolve
pods
over
time,
and
if
we
had
made
everything
mutable,
we
would
have
drowned
in
a
sea
of
oh.
H
This
is
just
another
bug,
so
I,
don't
think
immutability
immutability
got
a
new,
v1
type
doesn't
seem
to
be
an
issue.
Immutability
got
a
new
beta
type
is
probably
better
immutability
and
alpha,
it
probably
doesn't
matter.
Maybe
just
the
issue
is
we
went
immutable
too
late
because
things
were
in
real
use
and,
like
I
think
that's.
The
thing
is
like
beta
is
GA
like
we
can't
like.
We
pretend
that
GA
is
GA
and
every
time
we've
done
it.
It's
come
with
a
cost
to
some
user.
H
When
we
change
things
at
GA-
and
it's
not
perfect
so
earlier,
I
think
we
can
say
immutability
is
useful,
but
you
can't
add
a
field
that
is
immutable
to
an
existing
API
without
adding
a
whole
context
around
it
like,
if
you
added
a
new
optional,
struct
and
inside
that
struct
was
an
immutable
field
that
might
be
okay,
so
yeah
I.
Think
immutability
is.
I
One
example
of
a
like
schema
change,
for
which
we
need
a
general
mechanism
of
breaking
the
news
gently
to
old
clients.
Yes,
I
solving
it
specifically
for
immutability,
but
not
for
other
things
that
we
might
want
to
do
to
objects
like
like
key
duplication
enforcement,
I,
think
that's
to
single
purpose
and
and
there
there
are
multiple
issues
open
on
some
sort
of
validation,
ratcheting.
It's
really
the
same
problem,
but
it
has
to
go
in
both
directions
like.
H
G
Way
he's
like
observing
an
object
at
two
different
points
in
time,
like
the
main
reason
we
put
immutable
things
in
place
is
because
the
controller,
that's
actuated,
that
state
it's
hard
or
difficult
or
impossible
for
it
to
make
that
change,
and
so
relaxing
immutability
restrictions
when
it's
accompanied
by
like
making
the
controller
responsible
for
that.
Well,.
H
To
do
that,
and
arguably
many
of
the
places
where
immutability
has
been
added
on
new
fields
was
just.
We
couldn't
come
up
with
a
reason
to
make
make
it
mutable,
but
maybe
we
weren't
properly
dealing
with
the
like
when
you're
adding
a
new
field,
you
should
be
able
to
articulate
what
can
change
and
when
can
it
can
change
most
of
the
arguments
for
immutability
and
older
existing
objects
with
us
coming
in
after
the
fact
and
being
like
you
know,
we
don't
really
know
what
we
want
to
make
mutable.
H
We've
gone
back
and
made
things
more
mutable,
so
once
they
follow
up
on
this,
then
like
right
now
we
have
at
least
two
separate
Doc's,
both
of
which
are
fairly
lengthy.
One
is
API
changes
and
one
is
API
conventions.
I
know
because
I
happen
to
look
at
them
this
week,
they're
both
in
the
range
of
double-digit
pages.
H
A
I
A
G
A
G
Guidelines
or
what
what
you
should
do
like
what
Tim
was
saying
about
if
you're
gonna
add
a
new
field,
if
you
make
it
immutable,
these
are
the
implications
and
you
basically
have
to
put
lots
of
special
handling
around
it
to
make
old
clients
whole
so
like
we.
We
need
to
explain
that
and
then,
when
we
should
explain
the
implicit
missions
for
making
a
field
immutable
and
a
new
type
I
think
that's
the
minimum
I'll.
I
H
I
A
H
Cool
so
surgically
Jordan
we're
gonna,
have
to
update
the
pluralization
section
of
big
guy
changes,
dock
to
cover
the
the
patch
case
and
the
IP
family
we're
working
through
what
the
results
there
is
going
to
be
a
on
the
document
better.
On
a
again
a
surgical
point,
you
can
add
an
AI
for
me
for
the
IP.
H
G
Yeah,
the
the
next
section
was
specific
reviews
that
are
targeting
118.
There
are
two
api's
that
are
making
progress
in
this
release
so
that
they
will
be.
The
plan
is
for
them
to
be
ready
to
promote,
to
be
one
and
one.
My
team,
so
ingress
has
a
set
of
changes
that
are
being
added
so
that
it
is
complete
to
promote
to
be
one
those
are
linked
there
and
then
certificate
signing
request.
S'
are
adding
support
for
multiple
signers,
the
that
PR
is
in
review.
G
Actually,
the
API
PR
is
reviewed
and
it's
pending
review
of
the
implementation.
So
those
are
the
the
two
API
is
making
progress
towards
GA
that
are
being
updated
in
118
and
then
there's
a
set
of
design
discussions
around
cron
job
and
pod
construction
budget
api's.
There
were
some
outstanding
questions
on
those,
and
so
those
are
in
the
those
are
links
to
the
updates,
and
that
is
the
work
for
that
would
likely
happen
in
119
and
the
last
item
I
did
a
review
of
the
cluster
API.
G
Do
you
went
off
of
two
if
you
went
out
for
three
update,
and
so
that
is
a
set
of
conversions
and
defaulting
and
validation,
and
so
I
linked
it
to
the
notes
for
that
and
it
recorded.
But
I
don't
have
the
link
for
that
I'll
try
to
get
Andy
to
throw
a
link
to
the
recording,
but
so
that
was
that
was
a
couple.
Our
review
of
crt-based
multi
version
API
and
they
were
fair.