►
From YouTube: Cluster API Provider Azure - 2020-20-02
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
C
I'm
new
I
used
to
work
with
a
scintilla
transfer
teams.
I,
don't
know
if
you
guys
know
who
aces
yeah
yeah.
My
name
is
Tiffany
Saddam
and
we
are
kind
of
using
the
version.
A
cluster
API
in
our
production
and
we
I
just
wanted
to
join
in
so
I'd,
be
in
the
loop
with
you
guys,
possibly
even
to
work
or
request
new
features.
If
you
guys
don't
have
it
yet
yeah.
D
You
yeah
I,
am
percussion,
I
have
been
attending
for
two
weeks,
I
deal
with
actually
the
metal
cube
and
bare
metal
operator
and
cluster
API
uses
some
of
the
artists.
There
is
some
connection
between
the
two,
so
I,
don't
know
full
things.
I
am
also
new
I'm
trying
to
learn
so
I'm
part
of
this.
Thank
you.
A
A
B
A
A
Sounds
good,
alright,
so
I
think
we
can
do
the
project
board
review
it's
something
that
we
I
got
access
to
and
we
made
any
project
for
it
even
helped
out
a
lot
so
Thank
You
Steven.
We
can
do
that,
maybe
at
the
maybe
at
the
end,
because
we
want
to
go
through
some
specific
issues
and
hopefully
it
will
get
some
volunteers
to
help
out
with
some
stuff.
So
let's
do
that
at
the
end.
So,
let's
start
with
an
open
discussion.
Cecille
with
you
went
out
for
three
updates.
E
Sure
so,
for
those
who
were
in
there
last
week,
we
have
everyone
outfit
to
release,
so
master
is
not
targeting
v1
off
for
three
happens
in
cluster
API
master
for
the
last
or
up
until
today.
So
master
was
a
little
bit
unstable
master
of
cab
Z
because
we
were
pulling
new
changes
as
they
were
merging
in
capi,
which
means
we
got
affected
by
some
breaking
changes
in
some
of
our
end
to
ends,
but
this
should
be
resolved
now,
I
actually
just
merged
up
your
like
less
than
an
hour
ago.
E
That
puts
us
back
up
to
date
with
the
latest
changes
in
khaki
master,
and
it
also
makes
us
use
the
new
release
candidate
release
that
cappy
has
released,
and
so
we're
now
targeting
copy
0
dot,
3.0
RC,
1
and
we'll
keep
updating
that
as
numerous
candidates
come
out.
But
now
we
can
at
least
decide
when
we're.
You
know
taking
a
new
changes.
So
that's
there.
We
also
updated.
E
B
B
E
A
B
E
B
E
B
E
Yeah,
we
just
need
to
release
a
patch
for
b1a4,
because
we
need
the
preserve
unknown
fields
marker
to
be
false
for
clusters.
I
get
created
a
new
one,
also
in
order
for
them
to
later
be
upgradeable
to
anyone
off
the
three
so
that
PR
has
been
merged
in
the
release
branch,
and
we
just
need
to
cut
a
new
release.
E
E
B
So
the
kind
of
the
the
note
here
about
pushing
more
content
to
the
branch.
Basically,
the
way
our
image
building
container
image
building
works,
is
it
triggers
it
triggers
on
post,
submit
right
so
every
time
we
commit
something
there
is
a
TCP
job
that
runs
our
Google
Cloud
build
job
that
runs
in
the.
B
Build
our
and
build
and
push
the
images
right,
so
we
the
way
cluster
API
kind
of
does
it
is
they
only
enable
they
only
enable
image,
pushing
on
the
active
release
branch
and
for
a
few
reasons
like
one,
we
probably
shouldn't
be
pushing
images
to
branches
that
no
longer
need
them,
but
also
some
of
the
older
branches
will
have
are
not
necessarily
wired
up
for
that
automation.
Yet
the
the
automation
is
a
newer
thing.
B
It's
been
it's
been
around
for
a
little
bit,
but
the
previous
branches
are
not
wired
to
do
the
image
pushing
so
the
master.
Currently,
the
master
branch
and
the
release
0-3
branch,
which
is
the
V
1
alpha
2
release
branch,
will
support
image.
Pushing
so
we
need
to
do
now
is
push
an
additional
commit
on
to
the
release
branch
to
trigger
that
again.
So
then,
once
we
have
that
we'll
have
a
new
container
image
and
then
we
can
use
Tanner
image
and
promote
that
to
be
a
production
image
for
the
next
release,
so
we're
gonna.
E
E
B
B
We
mentioned
this
and
the
previous
meeting
that
wasn't
able
to
attend,
but
we
have
some
new
folks
right
well.
Well,
some
maintainer
changes,
I,
guess
right,
so
so
Nick
Lane
a
soggiest
you
may
know
who
my
has
stepped
down.
He
doesn't
have
time
to
focus
on
captaincy
it's
with
the
with
a
job
change,
so
he
has
stepped
down.
He
says
thank
you.
It
was
a
pleasure
yeah,
yada,
yada
and
and
later
we
have
introduced
promoted
as
a
reviewer.
You've
been
doing
some
awesome
work.
So
thank
you
for
for
being
part
of
the
project.
Thank
you.
F
H
So,
as
we
start
growing,
it
seems
like
we'll
probably
need
to
be
able
to
propose
some
wider
changes.
Perhaps
you
know
disrupt
all
changes
possible
and
to
do
so,
we
should
probably
have
some
proposal
process
follow
the
same
processes
that
are
out
there
already,
and
you
know,
figure
out
what
is
the
what's
the
light-touch
way.
When
do,
we
need
heavier
touch
like
when
we
need
like
the
full-on
proposal.
When
do
we
need
a
high
proposal?
I,
don't
know
what
makes
sense
so.
B
D
B
See
a
ep9
cluster
API
enhancement
proposal,
so
when
I
saw
the
additional
proposal
get
introduced
in
our
area,
I
was
like.
Oh
please,
no
more
so
I
agree
that
we
do
need
a
light
touch
way
of
doing
this.
We
need
to
figure
out
I
think
that,
if
we're
going
to
say
that
okay
caps
cap
cap,
this
are
the
ones
that
we
go
with,
then
they
should
be
in
one
place.
B
B
So
I
think
that
we
should
talk
a
little
with
the
I
was
talking
a
little
with
some
of
the
cluster
API
maintainer
before
this
I
think
that
we
should
probably
keep
them
in
one
place,
which
is
cluster
API,
but
I.
Think,
for
the
purposes
of
our
repo,
we
can
prompt
have
a
feature
request
proposal
issue
template
that
would
start
the
discussion
that
would
fold
into
roll
into
eventually
some
proposal,
whether
it's
on
a
Google
Doc
that
gets
turned
into
a
markdown
or
which
is
kind
of
usually
how
people
do
it
anyway.
H
B
I
think
the
I
think
the
first
step
is
is
definitely
the
issue
template.
Let's
make
it
as
lightweight
as
possible.
There
is
actively
actually
an
active
proposal
around
enhancing
caps
right.
The
so
I'm
gonna
link
that
in
the
chat
and
that
one
has
some
good
ideas
on
what
to
do
with
caps
and
maybe
that
transfers
over
to
what
we
do
with
cat
cat
cat
caps.
B
So
take
a
moment,
if
you
have
time
take
a
moment
and
check
out
some
of
the
some
of
the
discussion
there.
It's
not
blocking,
because
this
is
essentially
you
know.
This
is
top
level
process
for
the
project
as
opposed
to
kind
of
internal
process
for
the
sake
for
the
sub
project.
So
I
think
that
we
can
diverge
there
a
little
bit,
but
it's
I
think
it's
still
valuable
to
take
some
notes
from
from
what
we're
doing
there,
specifically
probably
around
the
submission
of
the
submission
template
right.
B
So
it's
basically
like
you
know
the
submission
template
says
something
like
hey.
You
know:
choose
the
sponsoring
cig
propose
your
idea
to
the
say
great
and
this
those
are
kind
of
obviated
by
the
fact
that
we're
in
cluster
lifecycle-
and
you
know-
and
we
know
exactly
who
this
is
being
proposed
to
right.
B
So
so
I
think
it's
you
know
flip
the
idea,
Yeah
right
so
floating
the
idea
would
be
opening
the
issue
template
right,
and
you
know
if
it's
I
think
the
key
part
of
this
is
like
making
sure
that
people
don't
go
into
the
weeds
building
a
proposal
that
may
not
get
accepted
right,
so
I
think
the
first.
The
first
point
of
this
is
like
make
sure
you
actually
propose
it
and
discuss
it
before
you
start.
H
E
B
So
the
difference
between
the
read
the
primary
difference
between
repo
based
project
boards
and
or
global
project
boards
is
that
you
can
actually
control
control
permissions
right
who
has
access
to
rewrite
and
admin.
The
project
boards,
where
is
in
the
repo
project
word
permissions,
are,
are
essentially
dedicated
to
the
the
the
admins
maintainer
of
the
repo,
so
people
who
have
people
have
right
and
admin
access
to
the
repo
will
be
able
to
manipulate
the
project
board
right,
so
well.
B
I
wanted
to
make
sure
than
here
is
that
we
kind
of
split
the
the
boundaries
between
like
who
can
do
that
and
who
can
maintain
the
code.
I
think
those
should
be
explicit.
So
what
we
did
was
we
created
a
separate,
a
separate
github
team
called
cluster
API
cluster
API
provider,
Azure
p.m.
right
and
the
PM's
group
includes
everyone
in
the
maintainer
through
plus
RIA
right,
so
that
that
group
is
assigned
with
write
access,
as
well
as
the
maintainer
group.
B
B
B
A
B
B
B
A
We
updated
the
other
board,
so
let
me
go
back
ashes
meeting
and
refix
this
one
too
something
it's
a
little
bit
more
accurate
and
then
we
can
go
through
it
next
time
but
yeah.
This
is
our
new
board
and
it's
here
cool.
So
now
we
can
go
to
triaging
issues
which
I
think
Cecile
is
gonna,
lead
right
to
see.
Oh
okay,.
B
E
E
A
B
E
F
B
So
bad
clogged.
So
basically,
if
you
see
Surrey,
if
you
can
go
to
the
bottom
left
or
the
right
hand,
side
of
a
column
of
the
leftmost
column,
so
where
you
were
but
where
it
says
manage
sorry,
go
all
the
way
to
the
bottom
left
of
the
screen
and
then
you'll
see
manage
at
the
bus
yeah.
So
the
way
this
board
is
set
up
is
as
a
there's,
a
touch
of
automation
on
it.
B
For
like
autumn,
it
was
I
think
it's
called
automate
automated
comp
Kanban
with
reviews
or
something
so
when
they
initially
create
one
of
those
boards.
You
see
a
like
a
to-do
column,
I,
think
in
progress,
review,
requested
review,
approved
and
then
done.
Right
I
usually
tweak
my
boards
a
little
bit
so
that
we
have
multiple
done
columns.
So
we
can
compare
what
we've
done
across
different
quarters.
B
There's
an
in-progress
I
get
rid
of
the
review
approved
column,
because
if
something
is
approved,
our
automation
is
going
to
carry
that
into
the
done
status
pretty
quickly.
So
there's
no
need
for
that
column.
Review
requested
our
our
pull
requests
with
reviews
in
progress
basically,
and
then
the
backlog
so
I
reconfigure
the
to
do
column
to
not
have
any
automation
on
it,
and
then
the
backlog
becomes
the
to
do
column
right.
So
any
issue
that
is
like
way
like
this
says
any
issue:
that's
newly
added
will
pop
up
on
will
pop
up
on
the
backlog.
E
H
F
E
A
B
A
E
A
Is
that,
okay,
with
everyone
cool
all
right,
so
refactor
customize
can
pick
folder
that
is
currently
in
progress
as
we
discussed
before.
These
are
the
same
things:
okay,
this
isn't
in
progress,
but
we
want
to
do
it.
We
want
to
kind
of
that
what
it
would
look
like
if
we
use
as
or
manage
identities
instead
of
service
principles.
This
is
something
where
someone
could
go
and
add
more
information
if
they
wanted
to.
So
we
get
someone
else
on
it,
so
just
kind
of
leave.
A
That
is
that
we
also
are
working
to
enable
accelerated
networking
I,
don't
think
we're
actually
working
on
that
right
now,
right,
it's
cool
investigating
vmss.
So
this
was
the
machine
pool
work
that
when
Lee
was
working
on
don't
know
how
far
we've
gone
for
specifically
vetting
vmss,
though,
within
that
I.
E
F
B
B
B
It
was
not
on
the
I,
don't
believe
it
was
on
the
board
prior
to
prior
to
the
prior
to
being
reviewed
right.
So
so
for
four
things
that
are
being
so
for
only
four
pull
requests
that
are
being
reviewed.
Will
they
be
dragged
into
the
review
in
progress
right
assuming
that
you
actually
do
a
review
and
not
do
like
single
comments
right?
So
if
you
actually
go
for
like
comment
or
comment
or
approved
or
request
change
or
changes
from
the
github
workflow,
then
it'll
actually
pull
into
review
in
progress.
E
B
A
C
B
A
B
I
would
say
for
just
note
for
maintainer
x'
if
you
are
looking
at
a
PR,
if
a
PR
has
been
open,
try
to
make
sure
that
it
it
lands
on
the
project
board.
That
way
this
automation
will
take
place.
I
know
it's
not
perfect,
and
it's
not
honestly.
The
repo
repo
projects
are
maybe
more
convenient
in
some
ways,
but
they
don't
give
us
the
flexibility
to
have
layers
of
people
who
can
do
reviews
on
project
board
and
triage
versus
people
who
can
actually
approve
code
right.
B
So
there's
a
milestone:
applier
plugin
for
prow,
which
ok,
we
don't
have
it
configured
right
now,
but
you
can
auto
milestone
so
you'll
see
for
the
kubernetes
configuration
for
these
branches
that
will
automatically
go
into
these
milestones.
All
merge
right
if
we
want
to
free
milestone
something
if
we
want
a
milestone,
something
prior
to
merge,
as
you
believe
that,
but
if
we
configure
this
plug-in,
it's
a
little
easier
that
way.
This
is
basically
the
idea
behind.
This
was
make
sure
that
things
that
work
not
milestone
will
automatically
get
milestone
on
merge.