►
From YouTube: 20210311 SIG Architecture 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).
B
Oh
hi
dems
just
to
answer
hibby's
question:
it's
nadir
jiwa
from
vmware.
C
Okay,
I'm
back,
I
have
a
new
laptop,
so
I
had
to
go.
Hunt
the
old
laptop
down
to
get
the
password
anyway.
We
are
recording
today
is
march
11th.
This
is
the
sikh
architecture
meeting
and
welcome
everybody.
C
So
let
me
open
up
the
agenda
and
the
first
thing
on
the
agenda
today
is
revised
api
reference
discussion
from
tim
and
irvifa.
I
don't
see
irvifa
here
tim.
Take
it
away.
B
E
B
B
Sorry
yeah,
I
just
saw
that
zoom
put
it
to
zero
and
I
was
like,
let's
pick
a
number
sorry
about
that
people.
You
are
a
co-host
now,
please
go
ahead,
cool
right,
so
yeah
back
to
the
topic
at
hand.
B
So
this
that
you
see
here
is
the
api
reference
that
I'm
talking
about
is
the
new
kubernetes
api
reference
I'll,
be
happy
to
try
and
answer
questions
on
that.
I
want
to
get
feedback
from
especially
sig
architecture
on
how
we're
going
to
adopt
this
and
what
we
need
to
do
before
that
happens
to
remind
people
there
is
an
old
api
reference.
B
B
B
This
is
the
api
reference
that
is
sort
of
canonical.
I
guess
a
lot
of
people
recognize
that
we
update
this
in
sig
docs
during
a
release
time.
It
is
a
big
long
page
and
there
are
no
links
to
the
rest
of
the
documentation,
which
is
a
bit
of
a
drawback
and
hence
philippe
martin
did
some
pretty
good
work
for
the
season
of
docs
to
generate
the
api
that
you
see
illustrated
here,
and
this
is
generated
documentation.
B
B
So
what
I
want
to
get
from
cigar
architecture
is
an
understanding
of,
what's
the
minimum
viable
product
to
use
this
new
api
reference
that
links
to
everything
else
and
uses
doxy
behind
the
scenes.
This
is
markdown
generated
from
golang
code
and
I
guess
it
uses
the
open
api
endpoint.
I
don't
actually
know
how
the
generation
works.
It
works
great
and
take
this
away.
So
what
do
we
need
to
do?.
C
So
tim
you
mentioned
that
there
was
a
bunch
of
feedback
from
jordan.
Was
some
of
that
already
rolled
into
what
you're
showing
us.
B
B
B
So
this
is
the
okd
which
is
based
on
kubernetes
api
reference,
and
if
I
jump
into
what
should
I
pick
a
resource
quota
which
is
part
of
kubernetes
inherited
into
okd,
the
url
is
like
this
and
there
is
a
relationship
between
the
the
urls
that
you'd
see
in
the
api
they're
right
on
the
page,
and
there
is
a
relationship
between
those
and
the
documentation.
Url.
B
The
existing
api
reference
isn't
really
clear
on
like
the
url
bit
you
see
like
if
you
look
at
pod
here,
it
doesn't
mention
that
slash
api,
anything
that's
not
shown,
but
that
might
be
a
really
important
thing
to
to
incorporate
and
there
is,
as
I
say,
like
a
relationship
between
a
resource
quota
here
and
the
fact
that
it's
core
and
it
being
slash
apy
api,
v1,
slash
resource
quotas,.
B
I'm
also
going
to
quickly
show
how
cube
vert
shows
that
quantity.
I
don't
know
what
you
call
these
to
be
honest,
like
there's,
probably
a
term
for
it,
but
quantity
is
not
an
api.
You
can't
kubecoil
create
a
quantity,
but
it's
a
thing
that
is
used
in
api
definitions
and
it's
useful
to
have
this
page
available
in
the
you
know
in
the
api.
So
in
the
api
reference
you
can
understand
what
a
quantity
is
and
if
I
want
to
tell
people,
oh
you
need
to
use
a
quantity
there.
B
So
I
guess
what
should
I
do
to
what
do
I
need
to
do
to
move
this
forward?
How
can
I
canvas
more
opinions
and
make
sure
that
we're
capturing
all
the
points
of
work
to
fix.
F
F
I
guess
my
first
question
is
like
is
what
nothing
stops:
incremental
improvement
right
so
like
what
you
showed
here,
comparing
q,
vert,
community
doc
or
open
shift
doc
like
that
all
seems
like
stuff
that
could
be
evolved
later,
I
guess
was
any
of
the
feedback
you
got
blocking.
B
So
one
of
the
challenges
is
around
if
you're
running,
say:
there's
the
cli
cube
couple
and
you
are
looking
at
the
help
for
something
coop
cuddle
will
show
you
links
to
pages.
B
So
I
had
a
pr
emerged
recently
to
link
from
the
help
for
cron
job,
to
you
know
the
cron
job
concept
page
and
a
particular
fragment
of
it,
and
that's
fine
for
linking
to
sort
of
a
page
about
cronjob,
because
let
me
just
actually
clarify
what
I
mean
by
the
cron
job
page.
I
mean
the
chrome
job
concept
page
in
in
workflows
so
it'll
be.
I
took
I
put
a
pr
in
so
that
the
the
relevant
bit
of
the
cron
job
api
links
here
for
additional
details
here,
specifically
not
a
problem.
B
That's
a
stable
url.
We
have
we're
going
to
make
commitments
that
if
we
change
that
url
there'll
be
a
redirect
trouble
is
that
most
of
the
links
now
look
like
this,
and
we
don't
really
want
to
keep
this
page
like.
I
don't
want
to
break
everyone's
links,
and
I
also
don't
want
to
keep
this
page.
So
it's
squaring
that
circle
that
I
want
to
help
with.
C
Okay,
so
my
feeling
tim
is:
let's
come
up
with
we
can't
dig
through.
Do
we
have
enough
information
on
how
how
many
times
a
page
got
hit?
I
think
we
have
it
for
the
website,
but.
B
I
don't
know
if
it's
for
the
doctor
the
reference
the
this
reference
does
not
take
part
in
google
analytics.
As
far
as
I
know,
because
it's
it's
a
bit
special.
So
not
really
for
this.
I
guess
we
could.
We
could
start
capturing
google
analytics,
which
might
be
useful,
but
I
suspect
I
would
really
like
to
get
this
done
before
those
and
the
statistics
would
be
useful
right.
C
So
that
was
one
angle
of
thinking.
The
other
angle
of
thinking
was
like
how
many
references
in
our
existing.
You
know
kubernetes
cabinets
yeah.
How
many
references
do
we
will
we
have
to
fix?
Will
we
have
time
to
fix
it
before
the
121
release.
B
Okay,
well,
I
think,
there's
a
reason
why
I
don't
think
that's
relevant,
which
is
old
releases,
because
not
many
people
will
adopt
1.21
like
I
know,
people
who
are
running
coop
cuddle,
like
1.14
and
just
for
the
supported
versions
like
I
want
to
make
sure
that
all
of
any
time
someone
does
coop
cuddle,
help
and
they're
running
any
supported
version
of
coop
cuddle
that
they
they
don't
just
see
a
broken
link.
We've
got
to
do
better
than
that.
C
Right
so
the
other
way
to
look
at
it
is.
C
Would
be
able
to
keep
both
around
to
transition.
B
Softly
yeah,
so
that's
a
good
question.
These
are
live
now.
You
are
seeing
the
live
kubernetes
website
now
this
is
behind
a
robots.txt.
B
Ask
me
in
the
chat,
if
you
don't
know
what
that
that
is,
but
it's
a
simple
blocking
thing
for
crawlers.
This
is
not
blocked
from
robot.txt,
because
that
would
be.
That
would
be
bad.
B
C
So
which
one
would
you
like
to
do?
If
you
ask
me,
I
would
just
say,
open
the
robot.txt
and
like
let
it
crawl
right
and
then
maybe
in
the
old
pages,
we
will
throw
up
a
banner
or
something
for
all
the
pages
saying
this
is
going
away.
So
please
go
to
this
other
new
link
as
the
base
for
the
documentation
from
now
on.
Let
it
run
for
one
cycle
and
then
rip
out
the
old
one
is
that
doable.
E
So
I'm
not
positive.
If
it's
doable
or
not.
My
question,
I
guess,
is
just:
is
there
a
reason
we
can't
do
redirects
like
I
don't
know
if
you
want
to
use
something
along
the
lines
of
an
aliases
or
whatever?
However,
it's
implemented
on
the
internals,
but
like
ideally,
we
would
have
pages
that
don't
exist
anymore,
but
there
is
a
page
that
people
should
be
looking
at
just
have
it
redirect
right
like
is
there
a
reason?
We
can't
do
that
and
we're
talking
about
deprecating
pages.
C
B
B
E
E
You
know
like
the
page
that
you're
going
to
has
moved
to
this
general
area.
This
may
be
the
right
direction
for
you
or
search
over
here.
I
don't
know
something
like
that
just
spitballing
here,
but
when
I've
dealt
with
this
sort
of
thing
before
it's
been
a
lot
of
you're
not
going
to
be
able
to
do
a
perfect
one-to-one
mapping,
but
people
are
usually
pretty
forgiving
as
long
as
the
link
doesn't
go.
Nowhere.
B
G
Hippie
go
for
it
on
the
receiving
side
of
the
redirect.
We
could
look
at
the
refer
url,
and
I
think
that
does
include
the
the
sub
object
so
that
it
could
possibly
be
like
you're
saying
in
javascript.
Some
type
of
this
is
likely
what
you
were
looking
for.
So.
B
We
use
a
cdn
yeah,
I
don't
know
if
referrer
is
available
to
javascript
code.
That
is
not
my
area
of
strength,
but
we
use
a
cdn
to
service,
so
we
don't
do
any
server
side
processing
during
serving
pages
right.
There.
B
Okay,
with
the
deprecation
page
afterwards
yeah,
I
don't
know
like
I'm
new
to
this
sake,
how
do
people
put
do
notes?
Is
it
like
in
line
in
the
agenda
or
what
yeah
you
can
just
okay
I'll
when
I've
like
done
my
piece
off
I'll,
put
some
notes
in
the
agenda
based
on
what
I'm
jotting
down
you're
thinking
like,
but
basically
dooms
you're,
saying
like
one
cycle.
B
No,
like
one
thing,
I'm
glad
you
didn't
say
is:
let's
have
a
cap,
and
what
have
you
no
but
like
this
was
your
chance
to
ask.
B
And
I
guess
I
think
that
jordan's
feedback
was
that
the
let
me
show
you
again,
the
the
new
urls,
the
new
urls
are
a
bit
iffy,
it's
a
strong
word
but
problematic,
because
you
cannot
predict
this
part
of
the
url
based
on
knowing
the
name
of
the.
Let
me
pick
a
particular
thing.
So
network
policy,
you
don't
know
that
network
is
under
say,
network
policy
is
under
policies
or
not
network.
You
can't
it's
not
linked
to
the
sig
and
it's
not
linked
to
the
api
path.
C
And
what
I
think
here
is
like,
I
trust
you
as
a
sig
to
know
what
to
do
right
for
your.
You
know
consumers,
so
you
like
get
feedback
from
whoever
you
can
do
whatever
you
can
and
ship
it.
B
If
you
have
this
kind
of
mechanical
grouping,
then
it's
it's
kind
of
unarguable,
but
for
the
when,
when
the
grouping
is
a
you
know,
this
is
curated
and
I
think
what's
what's
probably,
the
compromise
is
that
we
have
oops
yeah.
We
have
this
kind
of
curated
page,
but
the
urls
that
things
go
to
have
that
I'm
gonna
borrow
cubert
style.
Now,
I'm
going
to
borrow
kitty
okd
style,
predictable,
urls
and
I'll
wrap
up
there.
If
there's
no
more
questions
or.
G
I
comments
a
question
around
the
your
current
detection
of
feature
flags,
both
the
apis
and
operations,
resources,
hidden
behind
them
and
the
output
data
and
the
detection
state
of
that,
and
I
also
dropped
a
link
to
kep.
I
believe
for
nikita,
who
has
from
adding
some
data
that
we
did
this
as
part
of
the
performance
operations,
and
we
had
done
a
lot
of
different
approaches
to
trying
to
generate
in
a
in
an
automated
way.
Knowing
what
is
supposed
to
be
fully
released
and
alpha
and
beta,
and
it's
not.
G
B
Of
the
stuff
sure,
well
I
mean
the
approach
sig
doc's
take
is
that
if
sig
graduates
are
featured
to
beta
or
ga,
it's
that
sig's
responsibility
to
manually
update
the
docs,
but
having
some
automation
on
this
would
be
like.
I
know
exactly
how
to
write
the
code
to
integrate
with
that.
You
know
list
of
feature
flags
and
status
once
it's
something
to
consume.
G
Where
within
the
docs,
because
maybe
we
could
use
this
information
as
well,
where
do
the
did
the
docs
get
updated
because
I'm
I'm
a
little
confused?
I
thought
this
was
automated
in
generation,
but
you
also
think
there's
a
question:
where
is
the
magic
connection.
B
Page,
so
here
is
your
table
h.
This
is
a
markdown
table
of
feature
gates
and,
if
you're
graduating
a
feature
you're
going
to
change
this
and
if
you're
graduating
to
stable
you're
going
to
move
it
to
to
this,
and
none
of
that
is
generated
like.
A
C
D
Hey
folks,
I
will
be
very
brief.
I'm
kind
of
on
a
disclaimer
road
show
at
this
point,
so
a
lot
of
folks
in
this
meeting
have
been
very
helpful
and
resilient
this
week,
as
lockheed
myself,
have
pestered
them
relentlessly
about
the
effects
of
the
exec
probe.
Timeout
feature
gate.
So
a
little
bit
of
background
in
the
120
release
cycle,
exec
probe
timeouts
were
finally
fixed
definitively,
and
so
they
are
now
respected,
but
as
a
a
kind
of
carrot
to
folks
who
are
using
exec
probes
with
long
timeouts.
D
Historically,
a
feature
gate
was
shipped
with
that
that
allows
folks
to
essentially
opt
out
of
that
fixed
behavior,
so
that
you
know
kubernetes
service
providers
and
folks
can
provide
their
customers
maybe
more
time
to
communicate
that
this
is
effectively
a
functional
change
with
the
adoption
of
120.
D
so
that
background
being
established.
What
lockheed
I
have
been
working
to
do
this
week
is
to
develop
a
little
bit
more
formality
about
when
we're
going
to
retire.
That
feature
gate
so
that
work
has
largely
been
done.
I'm
going
to
paste
an
issue
in
the
chat
here.
This
is
my
issue,
so
if
the
canonical
issue
ends
up
being
somewhere
else,
I'll
make
sure
that
this
has
a
link
to
it.
D
The
to-do
item
for
us
going
forward
is
to
develop
a
consensus
as
a
community
when
we're
going
to
officially
retire.
This
feature
gate,
so
if
you
have
a
vested
interest
in
that
feature,
gate
being
retired
sooner
or
later
feel
free
to
hop
in
and
participate,
and
then
one
further
point
is
that
we
have
reverted.
A
recent
change
that
promoted
the
behaviors
of
exec
probe
timeout,
the
fix
to
conformance
test.
D
We've
reverted
that
so
that's
no
longer
a
conformance
test,
and
anybody
here
who
can
better
clarify
this
in
terms
of
policy
than
me
feel
free
to
hop
in.
But
basically
we
aren't
able
to
decompose
we're
not
able
to,
within
the
conformance
test,
be
super
sensitive
to
a
feature
gate
being
on
or
off,
and
so
what
this
means
is
that
folks,
who
are
opting
into
that
feature
opting
out
of
the
fix
by
opting
out
of
the
feature
gate.
D
I
know
that
sounds
confusing,
but
exec
probe
timeout
equals
false,
is
the
kind
of
keep
the
old
behavior
gesture.
So,
if
you're
in
that
scenario
in
your
cluster
you're
going
to
fail
conformance
if
we
run
those
tests,
so
those
tests
have
been
removed
and
the
the
agreement
at
this
point
is
that
when
that
feature,
gate
is
officially
retired,
then
we'll
re-add
that
as
a
conformance
test.
C
I
No,
I
don't
have
much
to
add
yeah,
like
we
kind
of
anticipated
that
this
change
could
be
disruptive
and
we
kind
of
said
that
it
was
worth
biting
the
bullet
because
basically,
cubelet
was
ignoring.
You
know
a
v1
api
field,
yeah
it's
unfortunate
like
yeah
click,
the
whole
conformance
thing.
I
I
think
that
makes
sense
right,
like
a
lot
of
people
want
to
or
a
lot
of
platforms
want
to
keep
the
behavior
off
for
good
reason
and
doing
that
breaks
conformance,
which
is
unfortunate,
but
yeah
like
I
think
our
decision
to
like
push
the
feature
like
keep
the
feature
gate
on
or
keep
the
feature
gate
as
long
as
we
need
to
so
people
can
continue
to
opt
out
and
removing
the
conformance
test
seems
like
a
reasonable
thing
to
do.
Right
now,.
C
So
andrew
you
still
have
the
pen
on
the
cap
and
you
will
volunteer
to
put
put
things
back
the
way
it
should
be
down
the
road.
C
So
it
goes
back
to
lucky
and
jack.
How
much
time
do
you
need
given
what
you
know
now
and
then,
one
week
ago,.
D
D
Testing
really
the
boundaries
of
these
particular
edge
cases,
and
one
thing
I've
discovered
in
the
azure
test
that
I've
done
so
this
is
azure
specific,
plus
a
very
particular
build
of
container
d,
but
the
the
side
effects
are
actually
nastier
if
you're
running
container
d
and
so
that,
knowing
that
would
suggest
that
we
would
want
to
accelerate
disabling
this
feature
gate
to
just
basically
force
customers
to
get
on
the
new
fixed
behavior,
because
we
do
have
some.
You
know
in
azure,
aks
and
other
kubernetes
sort
of
diy
scenarios.
D
There
are
lots
of
folks
using
container
d,
as
you
can
imagine
so,
for
those
it's
harder
to
communicate
when
you
have
all
this
sort
of
split
brain
messaging,
like
okay,
if
you're
on
container
d
definitely
do
this
if
you're
on
docker
we're
going
to
protect
you
for
for
future
releases.
So
I
think
to
answer
your
question.
Simply
dims,
I
would
probably
guess,
like
120
at
the
end
of
we'll,
go
through
122
and
then
starting
with
123
will
force
people
to
take
it
off
that.
But
I
think
we
should
discuss
that.
C
F
As
we
talked
and
signed
like
as
a
community,
we
sometimes
make
choices
that
seem
fine
and
then
it
can
sometimes
give
heartburn
on
people
to
think
that
we're
really
dogmatic
on
things
when
we're
really
open
to
just
feedback.
So
I
wanted
to
thank
lockheed
and
team
to
sharing
their
feedback.
F
F
I
think
like
in
this
case,
like
the
feature
gate
had
the
name
exec
probe
and
the
test
case
had
the
name
exec
probe,
that,
like
a
lentir
of
some
kind,
that
said,
are
you
sure,
like
we
could
have
had
the
the
obvious
of
like?
Oh,
we.
We
want
to
think
about
that.
F
I'm
not
sure
if
that's
good
enough
going
forward,
but
that
that
was
the
only
like
concrete
like
what
do
we
do
to
avoid
this
again
in
the
future,
because
there's
probably
other
aspects
that
we're
not
yet
aware
of
that
either
we
didn't
implement
as
we
desired
or
have
weird
edge
of
cases,
and
this
won't
be
the
only
time.
J
I
think
we're
already
doing
some
of
the
work
that's
going
to
help
right,
making
sure
that
we've
got
the
cryron
times,
for
example
in
the
in
the
ci
cd.
Thank
thanks
to
dems,
for
you
know,
pulling
some
stuff
then,
but
yeah
we're
making
too
many
pr
changes.
Thinking
that
you
know
that
this
this
looks
like
a
good
fix,
but
then
then
it's
like!
Oh
well,
you
know
all
these
other
runtimes
had
a
different
opinion
of
how
that
should
be
implemented
and
yeah.
F
F
We
need
to
establish
as
a
project,
maybe
an
upper
bound
on
a
grpc,
timeout
yep,
and
so
these
probes
like
right
now,
you
guys
got
a
value,
that's
larger
than
the
grpc
timeout,
and
we
won't
respect
that
either.
So
there's
going
to
be,
I
don't
know.
J
J
I
And
I
don't
know,
go
ahead,
andrew
yeah
and
I
don't
know
if
we
want
to
be
going
into
solutioning
in
this
meeting,
but
like
I'd,
be
more
than
happy
to
write
an
admission,
webhook
or
admission
control
in
an
api
server
that
like
can
expand
the
default
probe
timeout
for
exec
probes.
If
the
feature
gate
is
on
or
something
along
those
lines
like
because
we
can't
change
the
default
timeout
for
probes,
because
that
would
extend
the
default
timeout
for
other
types
of
probes.
I
J
C
G
One
of
the
things
we've
been
really
looking
forward
to
with
the
conformance
program
is
the
ability
to
look
at
in
two
different
places
for
future
flags
and
and
knowing
which
apis
operations,
in
which
kinds
and
resources
are
behind
those
flags.
What
we
haven't
done
yet
with
that
information
is
make
decisions
within
the
conformance
test
themselves
and
that's
something
we
might
want
to
look
at.
G
We
talked
pretty
heavily
over
the
years
around
having
different
profiles
or
something
where,
where
you
get
different
levels,
but
I
think
on
this
case,
where
we
have
something
that
we're
trying
to
to
do
some
testing
around,
we
might
be
able
to
use
feature
flags
themselves
say
as
a
conformance.
G
If
these
features
are
enabled,
then
we
want
to
go
ahead
and
ensure
that
we
test
whether
the
like
you
test
both
cases,
if
it's
off
make
sure
it's
off,
if
it's
on
make
sure
it's
on,
and
that
is
a
more
inclusive
test
for
everybody's
preferences
that
the
kubernetes
api
responds
as
designed
and
expected.
C
Okay,
clayton
did
you
have
anything
to
chime
in
because
you
were
in
the
some
of
these
discussions,
especially
around
conformance.
F
C
Any
last
word
jack.
D
Oh
just
a
second,
what
derek
mentioned
earlier.
In
fact,
everyone
has
been
extremely
flexible
in
this.
I
think
the
initial
engagement
was
extremely
sort
of
emergent
like
day
before
release,
so
if
there
are
any
any
feelings
there
that
things
weren't
flexible,
that
was
always
obvious
that
we
discovered
this
way
too
late
to
expect
any
changes.
So
it's
been
actually
extremely
positive
and
encouraging.
C
So
there
is
well-known
promotions
that
happen
dur
during
a
cycle
and
if
folks
can
look
out,
at
least
for
that
promotions,
pr
and
chime
in
whether
with
a
thumbs
up
or
a
thumbs
down
that
will
seriously
help
us,
because
right
now,
there's
only
a
few
of
us
taking
decisions.
We
would
like
more
eyes
on
it
so
that
we
can
catch
more.
Such
potential
issues.
D
G
To
see,
we
have
a
two-week
stoke
time
that
we
require
for
the
test
before
we
promote.
I
would
think
it'd
be
lovely
that
at
the
two-week
mark
prior
to
the
to
the
merge
we
go
ahead
and
create
that
promotion.
Pr,
so
that
that
discussion
has
two
weeks
of
conversation
and
anybody,
that's
part
of
the
conformance
team
and
if
people
that
are
interested
in
can't
have
those
two
weeks
to
talk
about
the
the
correctness
or
the
other
things
around.
G
C
Hippie,
maybe
another
label
called
promotion
of
some
kind
will
help
the
area.
Slash
conformance
is
too
noisy
at
this
point.
So.
G
G
Take
an
action
item
to
create
a
a
api
promotion,
flag
or
label
and
then
we'll
make
sure
that
that
somehow
maybe
not
automation
yet,
but
just
it
needs
two
weeks.
Conversation.
A
Yeah
I
like
what
you're
saying
here,
hippie
and
and
dims
jack.
We
should
like
pull
that
into
our
test
infrastructure
once
that
pf
pr's
up,
so
we
can
get
early
signal
because
the
net
effect
here
was
we
had
to
choose
between
either
being
conformant
in
the
service
which
we've
made
a
commitment
or
breaking
customers.
A
So
when
I
saw
jack
this
email
across
I'm
like
no,
no,
we
got
to
go
upstream
and
get
this
fixed.
I
don't
think
the
intent
here
was
to
have
non-conformance
at
the
risk
of
breaking
workloads
right,
so
we
should
like
pull
if
we
can
automate
and
get
signal
off
that
early
pr.
You
know
jack
kind
of
has
infrastructure
here
to
test
it
across
all
versions,
so
we
should
make
sure
we
pull
it
in
autumn
automate
it.
So
we
get
really
early
signal
of
how
that's
going
to
look
in
situational
environments.
A
D
In
fact,
that's
actually
what
happened?
We
just
we're
just
doing
it
in
the
super
sloppy
running
around
with
our
heads
cut
off
kind
of
way,
because
the
folks
on
our
side
did
notice
this.
This
change
in
conformance
signal
roughly
two
weeks
ago,
so
we're
here,
because
some
totally
ad
hoc
process
of
human
beings
kicked
off
so
next
time,
we'll
be
it'll,
be
much
more
seamless.
Hopefully,.
C
Sounds
good!
Thank
you.
Thanks
a
lot
for
engaging
with
everybody,
and
you
know
coming
to
a
conclusion
here,
any
any
last
thoughts.
Anybody
else
sergey
clayton,
nope,
okay,
let's
go
to
the
next
lorry
we
have
19
minutes.
Is
that
enough
for
you
laurie,
oh.
K
K
K
I've
also
teased
out
some
of
the
stages
that
are
oh.
I
froze
for
a
second
I've
already
also
teased
out
the
steps
for
the
prr
here,
which
those
are
pretty
clear
and
now
in
use
and
then
trying
to
establish
the
time
line
and
how
these
steps
all
fit.
So
we've
gotten
feedback
that
the
process
is
getting
heavy,
that
it's
hard
to.
Follow
that
there's
lots
of
steps
and
just
making
this
diagram.
K
If
you
click
in
closer,
you
know,
there's
there's
all
the
time
this,
but
there's
this
one
particular
case
where
this
is
happening,
and
so
when
we
have
a
lot
of
those,
that's
just
a
lot
of
context.
Switching
things
for
people
to
remember
and
subsequently
things
for
people
to
forget.
K
So
we've
been
talking
around
this
diagram
now
since
last
week
in
the
enhancement
sub
project,
to
see
where
we
can
remove
pain
points
to
see
where
we
can
simplify,
where
we
need
to
simplify
the
immediate
to
do
which
I've
noted
in
the
agenda
is.
We
want
to
take
an
action
around
this
step
and
actually
clear
up
what
level
of
process
and
review
do.
We
need
to
send
a
thing
through
to
get
it
in
a
release.
We
have
a
lot
of
things
going
to
release
team
for
review.
K
So
that
discussion
is
was
quite
active
last
night
and
I
shared
the
slack
thread
where
you
can
see
the
comments
and
feel
free
to
jump
in
on
that
if
you'd
like.
But
basically,
what
I'm
asking
this
group
to
do
is
if
you
could
take
a
look
at
this
mirror
board
and
share
your
feedback
about
the
process
where
it
could
be
improved,
where
it's
not
working
for
you,
where
you
think
you
would
abolish
steps,
get
rid
of
things
completely
or
tighten
up
whatever
feedback.
K
You
have
please
share
that
in
the
slack
channel,
because
I'm
biased,
but
I
think
this
is
an
incredibly
important
process.
This
is
how
we
get
feature
development
and
out
the
door
features
out
the
door,
and
if
this
is
what
we're
asking
people
to
do,
I
think
we
need
to
ask
ourselves
is:
is
this
real?
Is
this
realistic
if
we
add
any
more
steps
if
it
gets
more
complex.
C
K
C
You
do
have
like
a
natural
set
of
people
who,
this
time
signed
up
for
the
enhancements
process
in
the
various
six.
Those
would
be
your
first
line
of
people
who
would
give
you
feedback
on
whether
this
worked
the
cycle
because
they
opted
in,
and
so
that
would
be
the
first
set
of
people
that
you
need
to
poke
at,
and
the
second
set
of
people
is
like
the
people
who
didn't
sign
in
and
sign
up
for
the
process
like
they
might.
C
They
might
not
have
signed
up
for
various
reasons,
so
go
back
and
check
with
them
as
well,
and
then,
when
you
collect
the
feedback
and
put
together
a
plan
come
back
here
and
we
can
go
through
it
one
more
time.
C
The
sixth,
so
this
time
in
the
enhancements
team
six
were
allowed
to
opt
into
the
enhancements
process.
Oh
okay,
to
that
yeah
I
was
talking
about
that.
One
yeah.
K
Okay,
because
we've
also
have
a
couple
of
folks
opt-in
to
provide
feedback
as
users
of
the
process,
so
that
would
be
atlanta
houshmand
from
six
node
and
instrumentation
and
tim
hawkin,
so
we're
getting
some
good
feedback
user
feedback
from
them.
That's
what
I'm
bringing
this
topic
for
like
this
is
what
you
user
feedback
that
I
would
like
to
collect
from
as
many
people
as
possible.
K
We
all
have
different
perspectives
and
experience
levels
with
this
process,
so
the
more
feedback
we
have,
the
better
informed
our
decisions
will
be.
But
if
you
want
to
propose
actual
ideas
to
the
process,
that's
also
welcome
and
we
we
consider
that
and
discuss
that
in
the
channel
and
then
make
that
cap
recommendation
right.
Does
that.
C
Yeah
suggesting
every
yeah
everybody
who
is
a
consumer
of
this
process,
wear
your
individual
hat,
go,
go
talk
to
laurie
and
other
than
the
enhancements
and
refine
the
proposal
and
then
write
it
up
and
then
come
back.
C
One
last
question
I
had
is:
did
you
already
run
this
through
the
chairs
and
leads
call
lori.
K
Not
I've
shown
the
diagram,
but
because
it's
still
being
formed,
you
know
it's
the
same.
Ask
if
you
have
any
input
as
a
user
or
if
you
have
suggestions,
please
share,
but
I
haven't
given
any
official
presentation
just
because
the
discussion
is
quite
lively
at
the
moment
we
haven't
resolved
any
proposed
changes
yet,
and
I
think
this
is
the
first
one,
because
from
this
step
we
can
then
look
at
cascading
simplicity
right.
K
L
C
K
So
this
is
a
process
and
workflow
guide
that
I've
spun
up
here
spun
up
a
pr
about,
and
this
takes
all
of
the
input
that
I've
gotten
from
various
sigs
in
the
past
year
about
how
they
are
managing
their
processes
and
workflow.
What's
working
for
them
and
then
detailed
information
about
how
they're
executing
on
these
process
improvements
and
processes,
and
it's
a
compilation
of
all
of
that
into
a
guide
for
any
other
sig
chair
or
lead
or
motivated
contributor,
to
take
a
look
at
and
adapt
to
help
their
own
cigs.
So
it's
currently
being
reviewed.
K
Some
of
this
is
from
what
we've
done
in
sig
release
as
well.
I'm
a
program
manager
by
trade,
and
so
this
is
one
of
those
kind
of
weird
things
I
enjoy,
but
also
sig.
Node
has
a
lot
of
input
here
now
from
alana's
work
there
in
running
triage
and
managing
the
kep
backlog
and
some
of
the
other
activities.
K
My
ask
here
is:
if
you
would
like
to
consider
using
this
guide
in
your
own
sig,
please
feel
free
to
reach
out
in
the
chairs
and
leads
channel.
I
have
posted
there
in
slack
a
thread
and
some
folks
are
commenting
there.
I've
offered
in
the
chairs
and
leagues
meeting
to
have
some
small
breakout
groups
with
people
who
would
like
to
run
through
their
process
issues,
and
we
can
talk
about
them
and
then
devise
some
solutions
that
are
customized
to
their
needs.
So
I
think
you
know
you.
K
Every
process
needs
to
be
different
for
every
team
group.
So
that's
what
we'll
take
care
of
there
and
I
have
some
interest
in
project
project
board,
setup
and
road
mapping,
so
road
mapping
and
planning
your
caps
backlog
and
what
you
want
to
achieve
in
future
release
cycles,
and
I
will
mention
that,
from
this
conversation
there
has
spun
up
another
side
conversation
about
how
we
could
create
a
kubernetes
roadmap
like
what
would
be
the
obstacles
to
that
are
there
figs
who
would
participate
in
that
today.
K
If
that
opportunity
was
present,
a
cig,
a
kubernetes
roadmap
being
like
here
are
the
caps.
We
are
planning
for
the
next
few
cycles,
and
you
know
here
are
the
outcomes
we
want
to
see
and
putting
all
of
that
together
from
the
participating
cigs
and
then
publishing
that
for
users
and
contributors
to
understand
the
direction
that
their
groups
are
taking
and
then
that
the
overall
project
we're
taking.
K
I
will,
by
the
way
I
would
create
a
diagram.
Sorry
was
somebody
speaking
that
was
me:
okay,
sorry
feedback.
I
will
create
a
diagram
that
will
be
a
simplified
version
of
this,
because
it's
quite
long,
but
it
will
just
give
you
the
highlights
and
then
you
can
read
further.
If
you
want
more
detailed
information.
C
Yeah,
the
main
thing
I
see
here
laurie
is
like
we
need
more
of
you,
so
whatever
you
can
do
to
make
it
happen.
Well,
not
just
are
saying,
like
you
know,
container,
he
could
use
one
of
you
as
well.
C
So
so,
let's
you
know,
let's
find
more
people
and
coach
them
right
and
people
who
are
interested
in
this.
You
know
we
should
try
to
train
them
in
in
in
what
you're
putting
through
putting
together
here
and
let
them
lose
in
various
things,
and
you
know
make
things
better
overall,.
K
Yeah
I
mean
they're
signatures
and
tech
leads,
are
carrying
quite
heavy
workloads,
but
they're.
Also
people
like
me.
They
don't
necessarily
need
to
be
program
managers
but
they're
technical
contributors
who
also
really
enjoy
this
stuff.
So
if
we
can
actually
empower
them
to
do
this
work,
it
frees
up.
Chairs
and
tech
leads
to
focus
on
strategy
and
architecture
vision,
and
then
you
have
less
that
you
have
to
carry
so
alana
hashman
is
actually
going
to
be
onboarding
or
she's.
K
Talking
to
folks
about
onboarding,
chairs
and
tech
leads
through
mentoring,
and
this
this
could
be
a
compatible
part
of
that
is
to
also
help
with
the
process
side
of
things,
so
that
people
have
every
aspect
covered.
C
So
from
the
sick
architecture
side,
I
would
say:
let's
try
to
hit
all
the
different
sub
projects
and
see
if
we
can
get
get
something
like
this
going.
Definitely
in
you
know,
ep
is
here
so
conformance
for
sure,
code
organization,
it's
just
me
and
liggett
talking
to
each
other
every
week,
so
probably
not
there,
but
you
know
some
of
the
other
active
ones
for
sure.
So,
thanks
laurie.
C
Okay,
so
I'll
give
you
back
I'll,
give
you
back
six
minutes
of
your
time.
Thanks
a
lot.
Everyone
bye.