►
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
21
we
we
are
right
by
the
single
zip
code
upon
the
policies
that
may
simply
be
nice
to
each
other.
And
if
you
are
new
here,
please
raise
your
hand
to
reserve
yourself.
So
I'll
pause
it
for
that.
A
A
A
B
C
Sorry
I
couldn't
find
the
mute
button,
so
yeah
I
mean
kind
of
on
the
same
related
Thread
about
releases.
There
are
a
couple
of
bugs
that
were
identified
in
the
1.11
release,
so
we
should
have
a
patch
release
coming
out
soon.
I
guess
this
is
also
kind
of
a
PSA,
so
yeah.
The
first
one
is
private
endpoint
issue
for
managed
clusters
that
has
been
fixed
by
John
thanks
John,
it's
always
emerged.
C
Second,
one
is
this:
the
second
one
is
actually
a
bug
from
110,
but
we
just
found
but
there's
an
issue
with
the
arms
64
specific
Logic
for
the
VM
extension
that
has
also
been
fixed
and
then
the
last
one
is
an
issue
when
deleting
machine
pools,
that's
from
111
and
Jonathan
has
a
PR
out
thanks,
Jonathan
I
think
it's
almost
ready,
there's
just
a
couple
of
comments
about
removing
some
print
statements
yeah.
So
hopefully
we
can
get
that
last.
C
One
in
today
merge
it
into
the
release,
Branch
and
then
I,
guess,
question
for
folks.
Do
we
want
to
like
pair
and
doing
a
patch
release?
You
know,
hopefully,
and
before
end
of
day,
if
we
can
get
everything
merged?
Ci
pending.
C
All
right,
let's
yeah
so
we'll
aim
for
today
and
then
yeah
I,
don't
think,
there's
anything
else
that
is
yeah
I
guess
is
there
anything
else
that
is
in
the
queue
or
known
issues
that
you
should
be
paying
attention
to?
Besides
those
three.
A
A
C
C
Okay,
so
I
do
see.
We
have
a
112
Milestone.
So
when
you
do
a
pet,
a
minor
release,
I'm
asking
you,
since
you
did
the
2011
one,
but
when
you
do
minor
release,
part
of
the
process
is
to
create
the
new
Milestone
and
then
open
a
PR
against
the
plugins
code
in
Pro
to
make
sure
that
every
new
PR
that
merges
gets
put
in
the
new
Milestone,
okay.
C
Okay,
cool
the
Nelson's
there,
so
there's
already
yeah,
there's
already
quite
a
bit
in
there
should
we
is
that
everything
from
the
next
Mouse
I'm
guessing.
B
A
Yeah
makes
sense,
okay,
so
I
think
that
we
don't
want
to
do
anything
for
this
Milestone
right
now
like
this
is
what
we
have
and
are
we
part
folks,
going
to
add
stuff
async
or
do
English.
B
I
would
vote
just
since
no
one
else
seems
to
have
strong
opinions
that
we
don't
do
the
general
planning,
but
maybe
we
look
over
new
issues
in
PRS
quickly
and
just
make
sure
that
we
have
people
assigned
anything
important.
That's
come
up
that
nothing
slipped
through
the
cracks.
Unless
people
want
to
do.
General,
Milestone,
review.
E
We
have
34
there
and
I
think
there's
some
at
least
that
are
in
the
needs:
attention
state.
B
E
Yeah
I
would
scroll
to
the
bottom.
Maybe
look
look
at
the
ones
that
have
no
status
and
or
blocked
just
to
see.
If
there's
something
we
can,
if
there's
something
we
can
do.
A
Thank
you.
We
could
also
look
on
this
one
right
now
or
just
the
black
ones.
E
A
I,
don't
see
a
milestone
it
on
it
John.
Do
you
want
to
comment
anything
about
this.
D
Sure
so
this
PR
should
be
good
to
review.
I
think
it
would
be
good
to
get
this
in
before
we
start
doing
a
bunch
of
ASO
service
conversions,
which
we
still
need
to
open
issues
for
that
sort
of
thing.
A
C
A
A
Disable
local
accounts
for
AKs
a80
clusters,
I
can
Sean
and
Billy.
A
A
B
D
Yeah,
this
is
super
small
and
very
inconsequential
to
pretty
much
everything
so
yeah
I,
see
Cecil
did
approve
that.
So
thank
you.
A
So
next
review
has
been
done,
I
think,
let's
get
into
the
Blog
game.
First.
C
E
B
This
this
one,
we
just
have
to
wait
for
Cappy
to
upgrade
the
same
dependency
first,
so
we
just
have
to
wait.
We
could
close
the
pr,
but
then
dependabot
will
get
confused
and
not
open
it
again
until
there's
a
new
version.
So
generally
we
just
let
this
PR
dangle
as
a
reminder
that
at
some
point
we're
going
to
do
this.
A
A
C
I
think
there's
been
no
activity
on
it
for
a
while.
The
pr
needs
a
rebase,
and
it's
not
passing
a
test
so
makes
sense
right.
It's
in
ways
for
out
there,
nice.
A
F
So
this
there's
no
huge
rush
for
this
to
enter
into
main.
F
There
are
some
I've
observed
some
stuff
locally
when
I
test
that
doesn't
seem
to
Repro
here-
and
this
is
this
branch
is
proven
to
be
useful
for
me
for
running
various
functional
prototypes,
so
I
haven't
made
the
time
to
sort
of
raise
the
CI
concerns
to
the
rest
of
the
community
to
see
how
we
can
get
this
merged,
but
it's
just
it's
basically
ready
to
go
hard
to
sort
of
summarize
just
I
mean
I
shouldn't
say
it's
basically
where
to
go.
It's
basically
ready
for
review.
F
So
if
anybody
wants
to
look
at
it
and
accelerate
the
process
to
Main
Branch,
it
is
ready
for
that.
A
C
I
actually
added
a
comment
on
that:
PR
I,
don't
know
if
Jackie
saw
it
or
she
replied
and
I
don't
know
if
we
want
to
start
the
discussion
here,
but
I
am
I.
I
have
some
doubt
that
we
actually
want
this
to
ever
merge
to
camps
in
Maine.
So
I
think
this
is
a
great
test
to
have,
but
I
don't
think
it
should
be.
The
responsibility
of
the
kabsi
project
test,
the
Val
like
the
functionality
of
other
projects
and
I,
think
we're
missing
those
tests.
C
Upstream
in
culture,
otiscaler
and
I
would
rather
see
us
use
cabsy
to
test
autoscaler
in
the
autoscaler
projects
or
have
some
integration
tests
between
the
two.
But
I.
Don't
know
that.
Having
that
test
living
in
the
KFC
project
really
makes
sense,
I
don't
know,
if
that's
controversial,
probably
is,
but
it.
F
Might
be
working,
yeah
I
think
it
could
go
either
way.
This
is
probably
less
it's
probably
more
maintainable.
If,
if
on
behalf
of
so
this,
what
Cecile
this
and
backs
I'll
add
some
color
to
it.
Seal
said
we
are.
We
are
actually
not
testing.
There's
no
cap,
Z
cluster
API
integration.
It's
actually
a
sorry!
There's
no
cap,
Z
cluster
Auto
scalar
integration.
That
may
have
been
a
confusing
sentence
earlier.
The
the
what
we're
using
here
in
this
capsule
PR
is
the
cluster
API
provider
of
cluster
Auto
scaling.
F
So
any
cluster
API
provider
is,
should
be
able
to
run
the
cluster
API
provider
for
cluster
office
together.
So
we're
sort
of
validating
that
in
cap
Z
and
then
Cecilia
you're
correct
that
there
is
no
cluster
API
provider
and
and
test
coverage
in
the
Upstream
austro
Auto
scalar
project.
F
F
So
something
like
this
would
it's
possible
that
this
could
land
in
cap
Z
but
then
not
be
triggered
by
the
cap
C
project,
but
instead
of
being
triggered
by
the
cluster
API
project
that
would
put
all
the
plumbing
together.
So
we
could
talk
about
that
more
either
an
hour
later
or
we
could
move
all
this
stuff
into
the
cluster
Auto
scaler
project
and
do
a
bunch
of
Plumbing
importing
capsic
dependencies
that
might
be
more
complex
and
harder
to
maintain
I'm
I'm
open
to
either
it's
one
of
those.
You
can
do
anything
with
computers,
type
thing.
C
C
Scaler
Etc
run
a
periodic
test
because
I
think
that's
the
most
neutral
and
then
having
a
test
in
cabazy
which
uses
the
cluster
Auto
scalar
test
spec
like
refers
to
it
and
then
runs
the
same
test
Spike
with
Azure,
with
kab
Z
kind
of
similar
to
how
we
run
the
Cappy
tests
with
the
Azure
provider.
But
Cappy
itself
also
runs
the
same
class
with
docker,
so
I
I
do
think
it's
valuable
to
have
like
a
cab
Z
integration
of
the
test,
like
testing
that
it
works
on
Azure,
but
I
think.
C
F
Yeah
right
I
mean
well
that
makes
sense.
I
would
maybe
just
add
some
more
subtext
there.
There
could
be
Azure
specific
things
like
the
actual
behavioral
outcomes
of
this.
So
if
we
were
to
want
to
measure
how
does
Azure
performance
scaling
out
from
end
to
end
over
the
letter,
N
is
O
nodes.
That
would
be
an
Azure
specific
test
and
something
like
this
would
potentially
something.
But
in
the
meantime
just
so,
we
don't
derail
this
meeting
too
much
I'm
happy
to
keep
this
PR
in
the
current
state.
F
It
looks
like
waiting
on
author
is
the
appropriate,
like
high
level
classification,
with
the
expectation
that
it
doesn't
sound
like
we
have
consensus
to
merge
into
this
repo.
But
it's
it's
been
useful
to
me
for
other
efforts,
I'm
doing
with
bus
routes
here
so.
A
A
So
Jack,
so
you
you
want
to
keep
it
weight
on
author.
That
means.
Are
you
going
to
work
on
this
or
so
like
move
it
to
needs
review
so
that
folks
can
chime
in
and.
F
Kind
of
review,
yeah
I,
think
it's
in
the
I
think
it's
sort
of
correctly
classified
at
this
point
like
I.
Think
the
next
step
is
for
me
to
to
close
it
or
to
come
up
with
an
argument
that
should
continue
or
maybe
keep
it
open,
with
a
do
not
merge
until
we
get
a
similar
PR
in
some
other
repo.
As
a
reference
I
like.
D
A
A
D
Sorry
I
I
think
I
was
the
one
that
moved
this
into
wait
on
author,
because
I
think
there
were
some
kind
of
not
super
related
underlying
issues
that
we
might
have
found
with
this
PR,
so
I
I
think
yeah.
We
should
take
another
look
at
this,
but
yeah.
This
is
not
ready
to
merge,
I,
don't
think
or
review.
A
Bye
yeah
I
mean
we
can
decide
if
we
want
to
put
this
on
next.
One.
A
B
E
Throw
it
out
there
but
I'll
leave
it
up
to
the
Groupon.
If
you
wanted
to
do
this,
or
not
I
mean
there
is
we
got
through
I?
Think
half
of
the
bug
list,
that's
on
the
backlog
or
maybe
two-thirds
so
there's
still
a
bunch
of
bugs
that
haven't
ever
like
at
least
haven't
been
triaged
I,
don't
think
a
lot
of
them
are
older,
but
I'll
I'll
leave
it
up
to
the
group.
If
we
wanna
use
the
remaining
time
for
that
or
not.
E
So
the
ones
that
have
the
priority
backlog
have
been
triaged,
so,
if
you
go
down
to
it,
looks
like
around
18
is:
where
is
where
we
looks
like
stop
where
we
need
to
pick
up.
B
Yeah
this
I'm
actually
going
to
look
at
very
soon,
so
we
should
make
it
Priority
important
soon.
B
A
I
I
I,
don't
know
about
this.
One.
A
C
A
D
Yeah,
this
is
an
issue
that
I
was
running
into
when
I
was
testing
a
bunch
of
like
user
assignment
system,
identity,
things
and
I'm
a
little
surprised.
No
one
else
has
brought
this
up,
so
it's
probably
not
a
huge
deal,
so
I
guess
I
think
backlog
is
probably
a
decent
priority
for
this
one.
E
B
Why
don't
you
assign
me
to
this
and
I'll?
Take
a
look
because
I
think
they're
saying
that
the
image
comes
with
some
droppings
on
it.
A
E
F
Can
you
scroll
down?
Please
sorry
if
I
didn't
raise
hand
s
there's
a
red
at
some
point
there
we
go.
This
is
I,
keep
going
to
the
end
of
the
thread,
pretty
crazy,
that's
a
long
time
pretty
cool.
So
that
final
remark
for
me
yesterday,
I
would
have
wanted
that
to
put
this
into
waiting
on
author,
so
this
the
this
PR
will
either
close
because
it's
as
is
You,
probably
don't
want
to
accept
it
or
it
will
mutate
into
some
PR
or
some
different
implementation.
F
Is
there
did
I
do
something
wrong
in
terms
of
the
way
I
was
communicating
to
the
pr
author
to
not
nudge
it
in
there
automatically
should
I
have
like
gone
through
the
review
flow
and
said
request
changes.
E
A
E
A
E
Yeah
I
I
put
it
I
put
so
the
bottom
two
I,
those
are
the
recent
ones.
So
we
don't
need
to
review
those.
It's
just
I
think
these
three.
A
E
A
F
E
A
Matt
this
one
is:
do
you
have
any
comment.
B
On
this
yeah
it
means
we're
losing
logs
or
we're
not
seeing
some
logs
in
the
CI
entry
point
I
think,
because
the
canonical
way
to
set
this
up
for
controller
runtime
is
to
call
log
set
logger
in
the
test,
e2e
method
of
which
we
don't
have
one
in
CI
entry
point,
but
anyway,
there's
probably
some
way
to
work
around
it,
not
sure
what
it
is
join
me.
The
comment
there
go
ahead:
Cecile
yeah.
A
C
A
C
Yeah,
so
this
is
a
new
one.
From
a
few
days
ago,
I
started
looking
a
little
bit
seems
like
it's
a
very
occasional
flake
in
CI
and
I'm,
trying
to
gather
more
information,
but
for
now
I
guess
you
can
assign
me
and
put
it
as
far
awaiting
more
evidence
or
needs
triage,
whatever
we're
using
for
that.
C
A
Okay,
so
we
have
a
lot
of
colorful
relatives
now
any
comments.