►
From YouTube: Kubernetes 1.16.0-alpha.1 Live Release (Part Two)
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
So
hello,
hello,
everyone,
it
is
July
16th
2019.
This
is
the
second
part
of
the
one
16.0
alpha
one
release
in
the
so
before
we
start
again,
you
know
this
is
a
meeting
that
will
be
recorded
and
on
the
internet
for
posterity.
So
please
be
mindful
of
what
you
say:
please
be
sure
to
adhere
to
the
kubernetes
code
of
conduct
and
in
general,
just
be
excellent
to
each
other
right.
So
when
so
in
part,
one
we
ended
on
staging
the
release.
Rightly
so
there
is
a.
A
A
All
right
cool
so
back
to
the
directions,
we're
going
to
kick
off
the
so
we
finished
the
stage
section
and
I
verified
that
the
stage
is
actually
complete.
You
can
see
that
if
we
go
to
the
console
and
wait
for
it
to
load
and
okay,
so
we
see
that
so
we
mentioned
before
that.
We
saw
that
the
first
stage
had
failed
right
and
the
reason
I
will
will
poke
at
that
one
more
time.
A
The
reason
that
that
failed
was
because
it
was
searching
for
a
green,
build
right
and
it
couldn't
find
a
green
build
because
early
in
the
cycle,
we
tend
to
have
some
build
failures
that
need
to
be
cleaned
up
right.
So
we
can
see
right
here.
It
says
unable
to
find
a
green
set
of
test
results
right.
So
we
were
saying
that
that's
pretty
good,
that
our
our
release
tooling
provides
some
safeties
there
to
prevent
us
from
releasing
when
our
dashboards
are
not
good
right.
A
So
the
second
time
around
we
kicked
off
the
Onaga
sage
free,
build
blah
blah
blah
with
instead
with
the
Bildad
head
flag
right,
so
that
bill
that
head
flag
just
says,
ignore
the
checks
for
for
a
green
test.
What
I
want
you
to
do
instead
is
just
take
the
head
of
the
of
the
branch
that
I'm
of
the
repo
that
I'm
referencing
and
go
to
work
building
it
right.
So
that's
what
happened
here.
It
took
about
forty
nine
minutes
and
12
seconds
right.
A
A
What
I'm
gonna
do
is
we're
gonna
kick
off
the
the
release
stage
of
it,
because
I
think
it
takes
a
variable
amount
of
time
and
that
variable
amount
of
time,
I'm
unsure
of
so
we'll
kick
that
off
first
and
then
we'll
come
back
and
we'll
start
filling
out
the
the
cut
of
release
issue
right
normally
for
branch
managers,
anyone
who's
listening
to
this,
do
not
do
it
in
these
steps.
Do
make
sure
you
open
the
cutter
release
issue
first
and
and
log
the
appropriate
metrics
and
links
before
doing
that.
I'm
just
doing
that.
A
A
So
if
we
kind
of
see
that,
through
to
completion
right,
you
can
see
that
so,
let's
just
walk
through
this
really
quick
right
so
make
cross
was
successful.
It's
going
to
start
building
the
alpha
tree,
essentially
right,
so
you
can
see
it's
checking
out
116
alpha
one
and
sorry.
I
know
that
this
is
small.
So
let's
make
that
screen
a
little
bigger.
A
Right
so
at
this
point,
it's
starting
to
do
a
few
things
like
packaging
up
the
tar
balls
for
for
various
architectures
building,
the
docker
images
for
the
associated
kubernetes
components,
so
API
server,
controller
manager,
scheduler
proxy
and
the
cloud
controller
manager
right
and
making
sure
that
those
are
tagged
appropriately.
If,
with
one
116,
zero
alpha
dot,
one
right
and
tacking
that
to
where
we're
going
to
be
pushing
it
to
so
GCR
kubernetes
release
test
and
then
the
the
tag
right.
A
So
going
going
going
and
doing
the
same
for
multiple
architectures
right
and
when
that's
done
its
generating
a
set
of
release,
notes
for
for
116
right.
So
this
is
this
is
something
that
we
go
through
several
times
throughout
the
cycle.
The
the
release
notes
team
will
go
through
this
several
times
throughout
the
cycles
to
make
sure
that
these
are
appropriate
notes
and
verifying
that
with
the
cigs.
So
you
know,
we've
had
some
changes
to
the
way
we
do
release
notes.
So
we
now
have
a
release.
A
Note
site
realm
notes,
gates
io,
which
aggregates
some
of
this
from
a
JSON
document.
Instead,
so
there
is,
there
is
going
to
be
kind
of
a
split
brain
scenario
where
we
have
stuff
that
we
manage
within
the
repo
for
the
changelog
and
then
also
maintaining
this.
This
JSON
document
for
the
changelog
I
don't
have
all
of
the
details
on
that.
But
if
you
speak
to
Jeff
or
Sasha
or
Lindsey,
they
would
write
so.
A
A
A
So
if
we
want
to
see
what's
in
that
extra
directory,
GCE
and
anything
in
GC,
yeah
right
so
configurations
for
the
the
master,
the
node
and
shutdown
scripts,
as
well
as
some
windows,
artifacts
and
again,
the
associated
md5
sha-1
and
sha-512
hashes
for
those
artifacts.
Now,
if
we
check
out
this
bin
directory,
you
can
see
that
we've
got
binaries
for
again
multiple
architectures
and
this
will
probably
go
out
into
yeah.
So
let's
do
an
AMD
64
just
for
an
example
right
and
again
again
the
components
and
their
associated
hashes
right.
A
So
all
of
that
said,
I'm
feeling
pretty
good
about
it.
So,
let's,
let's
take
this
command,
that
the
output
gives
you
and
what
this
is
going
to
do
is
basically
we're
taking
a
build
number.
So
this
is
a.
This
is
a
head
at
the
time
that
we
ran
that
stage
right
so
the
truncated,
truncated
shop,
for
that
for
forehead
at
the
time,
as
well
as
like
a
build
number,
and
so
this
mentions
this
mentions
alpha
dot,
0
alpha
dot,
zero.
Will
this
will
become
dot
one?
A
A
Away
we
go
right
so
again,
GCB
manager
has
done
something
similar
to
what
we
saw
last
time.
It
basically
takes
the
it
wraps
Anagha
right
and
sends
off
a
command
to
Google
cloud
built
right.
So
if
we
wanted
to
do
it
with
an
go
instead,
this
would
be
the
command
that
we
would
run
right.
But
since
we're
submitting
to
cloud
build,
it
doesn't
really
matter
much
right.
A
You
can
see
it's
kicked
so
over
to
ever-important
housekeeping
great.
So
we
said
in
the
document:
that's
before
we
kick
this
stuff
off.
We
should
be
making
sure
that
we
are
opening
a
cut
release
issue
in
in
cig
release,
so
the
issue
template
will
describe
in
painful
detail
what
kind
of
things
you
should
be
collecting
right.
A
A
They
were
dealing,
but
yes,
yes,
so
this
gives
us
an
opportunity
to
you
know
it's.
It's
definitely
bookkeeping.
It's
also
like.
If
we
need
to
you
know
so,
we've
got
a
few
release.
Managers
that
span
across
multiple
time
zones
say
you
need
to
drop
this
task
right
and
do
something
different.
It
gives
it.
It
gives
people
an
opportunity
to
pick
up
where
you
left
off
right.
Yes,.
B
A
Let's
you
know
and
and
and
kind
of
doing
the
coordination
there
instead
of
via
diems
right.
So
let's
do
what
it
says,
and
you
know
one
of
the
things
is:
we
want
to
snapshot
masters
unhealthy
boards
right,
so
let's
go
to
master
blocking
and
currently
we've
got
one
failing
a
few
flaky
and
the
rest
passing
right.
So
we're
just
going
to
grab
that
and
let's
get
informing
too
right
so
in
forming
a
lot
more
ominous.
But
these
we're
removing
these
tests
out
and
I.
Don't
think
I
will
be
able
to
capture
everything
on
my
screen.
A
A
C
A
A
A
A
B
A
B
A
We'll
find
out
we'll
find
out
together
all
right
so
and
then
it
mentions
the
building
and
publish
of
the
Deb's
and
rpms
right.
This
only
happens
for
the
official
release.
This
is
when
we
contact
the
build
admins,
so
Alexandre
or
Linus
or
sue
me
right
and
we'll
contact
them
in
the
channel
or
we'll
reach
out
to
kubernetes
release
managers
at
Google,
Groups
comm,
to
request
the
Deb's
rpm
built
right.
A
The
reason
for
this
is
there
are
some
key
signing
things
that
happen,
and
you
know
the
the
Deb's
and
rpms
were
actually
published
to
a
to
a
repo
that
is
too
apt
and
yum
repos
that
are
managed
by
Google.
Currently,
so
we
are
in
the
we're
in
the
process
of
talking
about
what
the
design
looks
like
for
CN
CF
infra
hosted
apps
and
yum
repos,
so
that
conversation
is
happening
right
now,
once
that
is
done,
we'll
start
to
mock
out
what
that
flow
looks
like
and
start
switching
over
the
locations
for
we're
we're
landing.
Artifacts.
A
Okay,
so
it
looks
like
we're
almost
done
here
so
I
can
so
what
I'll
do
here
is
I
will
assign
myself
and
I
will
also
CC
release
managers,
which
is
a
well
all
cc.
Engine
release
engineering
rate,
so
release
managers
is
a
github
team.
So
actually,
maybe
it's
valuable
for
me
to
just
poke
at
these
really
quickly,
right,
so
org
right
so
kubernetes,
kubernetes,
orgs,
so
kubernetes,
kubernetes,
SIG's,
kubernetes,
client,
kubernetes,
incubator,
kubernetes
security,
not
security
actually
use
a
configuration,
or
maybe
security
does.
A
But
we
can't
see
it
uses
a
configuration
tool
for
github
called
parabola
sore
parry
bolus
or
something
I
never
got
the
pronunciation
right,
but
it's
a
tool
that
we,
we
wrote
up,
lives
in
prowl
and
allows
you
to
specify
a
config
for
the
github
org
right.
So
this
is
things
like
the
name
of
the
org,
the
company,
the
description,
whether
or
not
you
can
have
repo
and
and
org
projects,
what
the
default
permissions
are
or
what
who
can
create
repositories,
and
then
it
breaks
it
into
a
set
of
members,
admins
and
then
associated
teams
right.
A
A
Within
teams,
we've
got
a
few
different
teams.
Build
admins,
as
I
was
mentioning
there,
the
set
of
Googlers
with
access
to
publish
packages,
yada
yada,
yada
right.
These
are
the
people
associated
to
it,
and
I
also
include
the
sig
chairs,
so
Caleb
myself
and
Tim
pepper
here
for
the
sake
of
notifications
right.
So
this
group
that
this
group
has
no
special
access
on
on
github
permission
july's,
like
repo
permissions,
was
outside
of
notifications.
It's
an
it's.
A
It's
meant
to
do
notifications,
so
I
want
to
make
sure
that
sig
chairs
are
being
notified
on
the
same
things
that
the
that
the
build
admins
are
right.
There's
a
licensing
sub-project
right,
so
we've
got
dims
here.
Nikita
myself
and
Steve
Winslow
milestone,
maintainer
x',
milestone,
maintainer
x'
are
people
who
can
apply
the
milestone.
Our
status
commands
I.
Think
status
is
dead,
though
right.
So
we
probably
need
to
update
this
comment
and
it
gives
people
right
access
to
the
kubernetes
enhancements
repo.
A
The
reason
for
that
is
so
that
they
can
edit
the
descriptions
of
the
enhancement
tracking
issues
that
they
may
not
have
created
right.
So
lots
of
people
in
this
group
there's
coverage
for
there's
at
least
there
should
be
at
least
one
person
from
every
sig
within
this
group
to
apply
the
milestones
for
their
respective
SIG's
as
well
as
the
release
team
leads
some
of
the
some
of
the
roles
on
the
release
team
right.
So
communications
we've
got
the
enhancements
rolling
here.
A
The
patch
release
team
right,
so
the
patch
release
team
is
also
notifications.
Based,
doesn't
grant
any
permissions
right
now.
This
is
just
like
a
patch
release
team
we
want
to
like
we.
Can
you
tell
us
when
one
fifteen
one
is
coming
out
right,
so
anyone
on
the
call
wondering
when
one
fifteen
one
is
coming
out
is
going
to
be
Thursday.
If
you
are
not
aware
of
when
our
release
has
come
out.
A
In
general,
we
have
a
pretty
page
called
patch
releases
right
patch
releases
at
MD,
so
cig
release,
slash
releases,
slash
patch
releases
at
MD
right
and
we
keep
a
table.
We
keep
a
set
of
tables
up
to
date
here
right,
so
once
we
set
once
we
set
a
date,
will
PR
changes
to
these
tables
and
also
once
we
cut
a
new
minor
release,
will
also
update
this
right
to
let
you
know
so.
112
is
no
longer
support
that
update
happened
recently,
once
we
kicked
out
115
so
so
back
to
the
teams
right.
A
That
was
the
I
think
that
was
the
really
rudimentary
explanation
of
it.
There's
lots
of
doodads
and
gizmos
that
DIMMs
could
go
into
and
excruciating
detail
if
we
needed
to
so
there's
also
the
release
engineering
team.
This
is
the
one
that
we
actually
care
about
for
the
sake
of
this
call,
and
that
includes
members
of
the
release,
engineering
sub
project,
and
it
includes
everyone
who
is
either
a
build
admin,
patch
release,
team
branch
managers
or
the
release
managers
associates
great
I
think
it
also
includes
the
sig
chairs.
A
A
And
then
everyone
else
is
associated
roles
right,
so
build
admin
and
release
manager
associate
so
on
and
so
forth.
The
release
managers
team
write
the
release.
Managers
team
does
have
special
special
access
right.
This
one
allows
people
this
one
gives
you
write
access
to
kubernetes
kubernetes
right.
This
is
so.
This
is
one
that
we
guard
very
carefully.
A
You
can
see
that
the
the
Kate's
release
robot
is
in
this
one,
the
Kate's
release
robot.
Actually,
if
you
were
part
of
the
previous
call,
you
would
have
seen
that
we
have
a
what
the
hey
I
will
show
it
one
more
time
right.
We
have
this
stage
channel
under
GCB
in
the
release
and
their
really
release
repo
and
remember.
I
had
mentioned
that
we
have
a
key
in
kms
for
the
kubernetes
release,
robot
that
has
the
github
token
associated
to
it.
Right
and
again,
this
token
is
basically
for
encoded.
A
So
that
so,
by
giving
the
case
release
robot
access
to
this
team,
we
are
essentially
granting
our
build
process
access
to
cut
releases.
Do
you
make
changes
in
github
on
behalf
of
the
release
managers
group
right?
So
the
other
people
who
are
in
here
are
the
branch
managers
and
the
patch
release
team
notice
that
it's
only
the
branch
managers,
only
the
patch
release
team
for
now
right,
you'll
notice,
that
none
of
the
release
manager
associates
are
part
of
this
group
right.
A
So
again,
as
I
mentioned
before,
we
want
to
make
sure
that
we
are
building
a
level
of
trust
and
and
within
the
community
by
building
out
this
team,
so
people
who
prove
that
they
are
actively
actively
participating
to
sake,
release
care
about
they
care
about
the
health
and-
and
you
know,
and
innovation
of
the
release,
engineering
processes
will
be
people
who
will
be
considered
to
move
into
these
teams
that
have
that
kind
of
access
right.
But
again
we
do
not
remove
users
who
are
not
actively
doing
this
job
right.
A
A
All
right,
so
if
I
was
to
go
to
the
kubernetes
kubernetes
repo
and
check
out
issues
are,
let's
do
right,
pull
requests
right.
So,
if
I
look
for
pull
requests
with
I,
do
not
merge
label
right,
cherry-pick
not
approved
right.
So
this
is
another
reason
that
this
that
team
is
important
right.
So
when
someone
submits
a
cherry-pick
right,
we
have
a
script
that
runs
that
allows
you
to
automatically
generate
cherry
picks
based
on
PR
numbers
right.
So
it'll
give
you
a
little
message
like
this.
A
But
when
you
open
one
of
these
issues
it
will
automatically
the
the
CI
robot
will
automatically
do
this
right,
it'll
it'll
say:
hey
you're,
not
you're,
not
doing
this
for
the
master
branch.
So
it
must
be
a
cherry
pick
right
and
this
cherry
pick
was
not
approved.
Yet
all
right,
so
I'm
going
to
add
this.
Do
not
merge.
Cherry
picked,
not
approved
label
right,
so
you
can
see
from
my
screen
because
I'm
not
in
the
release
managers
team.
A
So
the
patch
release
manager
is
also
responsible
for
vetting.
The
fact
that
this
is
a
cherry
pick
that
should
go
into
a
patch
release
right-
and
you
know
some
of
the
reasons
for
doing
that.
Are
it's
fixing
a
critical
bug.
Are
we
introduced
a
regression
in
kubernetes
that
was
fixed
in
master
branch
and
new
to
be
cherry-picked
back
right?
Cherry-Pick
should
not
introduce
new
features?
They
should
not
introduce
vendor
changes
optimally,
assuming
that
the
vendor
change
isn't
required
to
fix,
said
critical
bug
fix
or
regression
right.
A
So
it's
up
to
the
patch
release
manager
again.
This
is
a
reason
why
there's
there's
an
additional
need
for
vetting
the
people
who
come
into
this
role
right,
because
the
the
patch
release
manager
needs
to
make
this
kind
of
call
right.
Is
this
something
that
we
should
actually
approve
to
cherry-pick
into
the
next
batch
release
right?
A
All
right
so
release
team
and
we
can
speed
through
now,
release
team
release.
Team
leads
cig
release
is
a
general
group
for
people
who
are
coming
into
the
release
team.
It's
just
an
it's
just
just
an
it's,
essentially
our
our
at
channel
right
also
for
for
github,
so
so
that's
top
for
the
teams
and,
let's
flip
back
to
this
issue
right.
A
A
A
A
A
Okay,
so
let's
go
back
to
cloud
build
and
all
will
be
revealed
soon
right,
so
we
saw
that
this
took
18
minutes
and
it
was
successful
so
just
scrolling
through
the
logs
very
quickly
right.
So
it
said
I'm
done
I
did
it.
Anagha
did
all
your
stuffs.
We
archives
a
release
on
G's
on
GCS.
We
updated
the
releases
page.
So,
let's
see,
if
some
of
that
is
actually
true
so.
A
A
Okay,
all
right
so
by
default,
and
if
you
go
back
to
the,
if
you,
if
you
go
back
to
the
playbook,
it
gives
you
the
answer
right
by
default,
all
of
the
Onaga
are
GCB
manager
commands
and
a
lot
of
the
thing.
A
lot
of
the
things
that
are
in
our
our
release,
tooling,
will
run
as
a
mock.
A
dry
run
right,
no
mock.
Ok,
god.
B
A
So
we
have
to
supply
this
new
mock
flag
to
make
sure
that
we
actually
do
the
things
that
we
said
we
wanted
to
do
right,
so
this
gives
us
an
opportunity
again.
This
is
another
failsafe
while
running
through
the
release
process,
especially
which
is
especially
helpful
as
we
start
to
onboard
more
people
into
this
thing.
Like
me
right
that
we
don't
we
don't
release
when
we
don't
mean
to
right.
A
So
now
we
mean
to
and
we're
actually
gonna
hit
the
button.
Yes
I
actually
want
to
do
that
right
so
see
it
even
gives
you
hey.
We're
really
gonna
do
this
now
and
I.
Sorry,
if
people
couldn't
see
my
screen
but
I'll
just
make
that
a
little
bigger.
So
yes,
I
do
want
to
do
a
new
mock
right,
so
one
more
time
off
to
GCB
right,
and
we
see
that
so
we
can
see
just
by
the
history.
A
All
told
we're
looking
at
close
to,
like
you
know
an
hour
and
10
minutes
or
so
right.
Different
parts
of
the
different
parts
of
the
release
cycle
will
take
different
amounts
of
time
right
so
because
we're
doing
an
alpha
release,
there's
nothing
too
crazy
going
on,
but
once
we
hit
beta
beta,
also
I
think
beta
also
prepares,
like
we've
gotten
to
the
point
where
we're
doing
a
branch
cut
right,
so
beta
does
some
additional
wizardry
that
we
can.
A
A
Where
do
we
start?
Where
do
we
start?
Maybe
it's
helpful
to
take
a
look
at
some
of
the
things
that
we're
bringing
in
some
of
the
things
that
we're
sourcing
as
we
run
a
knocko
right,
so
one
of
one
of
the
probably
the
more
important
ones
is
released.
I
thought
Sh
right
and
let's
check
that
out
right.
So
we
can.
A
A
A
You
know
certain
things
like
certain
things
we
actually
may
want
to
mask
the
return
values.
So
that's
fine
right,
but
we
need
to
make
sure
that
it's
ignored
in
shell
check
are
excluded
right.
So
one
of
the
things
you
may
notice,
as
going
as
you
go
through
this
code,
is
these
flags.
These
flag
underscores
right,
so
these
flags
are
dynamically
assigned
and
we
we
often
don't
know
what
the
value
of
them
are
until
the
run
gets
going
in.
Gcb
are
in
prowl
per
se
right.
So.
A
So
remember
we
have
these
additional
tags
here
and
some
configurations
here
so
build
that
head
no
mock,
so
these
underscore
these
underscore
variables
are
ones
that
are
leveraged
inside
of
GCB
right
and
get
interpreted
whatever,
whatever
you've
got
set
in
your
in
your
environment,
right,
so
release,
release,
tool,
repo
will
map
to
underscore
release,
jewelry,
bow
and
branch,
and
so
on
and
so
forth
right.
So
it's
translating
all
of
these.
A
These
actual
Nago
commands,
including
the
gnome
ox
and
the
official
and
build
version,
and
all
that
stuff
into
variables
that
are
either
assigned
or
not
assigned
within
GCB
right,
and
you
can
see
some
of
the
logic
here.
You
know
if
this
is
a
you
know,
if
official
is
exists
or
C
exists,
you
know
this.
This
will
conflict.
They
can't
be
the
you
know
that
that
can't
happen
at
the
same
time
if
their
official
flag
is
set
it'll
set.
A
A
A
A
A
A
A
A
A
A
B
A
B
C
B
B
A
B
A
B
A
C
A
A
Release
chair
I,
don't
understand
all
this
right
and,
like
that's
part
of
the
reason
for
for
this
call
to
make
sure
that,
like
we
can
all
get
to
the
same
place
where
we're
like
hey
well,
it
would
be
better
if
we
did
it
this
way
right
and
tease
out
improvements
in
this
process.
So
so
thank
you
for
for
coming
and
thank
you
for
the
compliments
and
and
all
that
stuff.
We're
gonna,
keep
doing
it
because
I
think
it
it.
A
It
seemed
like
it
was
valuable
last
cycle,
it
seems
like
it's
valuable
now
and
we're
learning
we're
kind
of
learning
as
we're
going
together.
So
so
thank
you.
Everyone
who
came
to
the
call
thank
you.
Everyone
who
is
going
to
watch
this
later
I
will
I
will
catch
y'all
at
the
next
one.
All
right,
thanks,
bye,
Mike.