►
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
B
Sure
I
mean
basically
one
nine
got
released
yesterday,
I.
Maybe
someone
can
summarize
the
sort
of
features
in
high
level
stuff
I
stared
at
the
list
for
a
long
time
and
it
and
no
themes,
kind
of
emerged
to
me.
Lots
of
fixes
around
machine
pools
some
follow-up
on
I
mean
you
could
read
the
list.
There's
a
lot
of
stuff
in
here.
I
I
had
trouble
summarizing
it,
but
CI
looks
very
green.
So
hopefully,
except
for
the
things
that
ashitosh
is
about
to
lay
down
it's
a
good
release.
B
B
A
C
C
Okay,
cool
and
I'll
have
a
follow-up
remark
on
that
in
a
second,
so
I
I'm
curious,
also
like
Matt
about
the
Cappy
bump,
because
there
is
additional
end
to
end
stuff
in
there
that
I
want
to
see
on
on
flaky
tests.
That
will
help
us
to
finally,
hopefully
make
progress
on
getting
rid
of
those
flakes,
but
I
think
if
it's
in
190
and
test
info
has
been
updated
to
release
one
nine
that
has
tested
for
been
updated
to
release
one
and
I
think
I
know
it
hasn't.
Okay.
C
So
once
we
do
that,
then
I
think
we'll
start
getting
that
additional
Cappy
signal,
because
the
jobs
that
I'm
referring
to
are
running
against
Maine
and
the
two
release
branches.
We're
actually
already
getting
that
against
me.
So
I
think,
thanks
for
letting
me
livestream
my
inner
monologue,
but
I
will
say
that
normally
we
would
release
a
patch
release
with
the
commits
in
the
next
minor
on
the
same
day
as
the
new
minor
release
right.
C
C
A
C
A
So,
okay,
so
I
think
we're
good
for
one
seven,
because
there's
nothing
in
there
for
one
eight
I
would
say:
let's
just
hold
since:
let's
talk
about
the
the
next
item
first
and
then
Circle
back
to
this,
but
I
think
we're
ready
in
any
case
to
start
well.
Actually,
let's
talk
about
the
next
item.
First
and
then
we
can
talk
about
test
info
as
well.
Let's
see
if
that
affects
it,
so
ashitosh
go
ahead.
Do
you
wanna
tell
us
about
what
you
found.
D
Yeah
I
think
the
first
issue
has
already
been
reported
by
from
just
gorgeous
then
slick
from
my
eye.
It
wouldn't
I,
didn't
see
it
earlier,
and
this
was
reported
in
one
of
the
downstream
pipelines.
So
I
took
a
look
at
this
one,
so
basically
this
has
to
do
with
so
what
happens?
Is
the
WebEx
does
not
trigger
the
logic
on
reads?
D
So
if
you
have
an
existing
Azure
cluster
object,
that
came
from
a
version
prior
to
this
change
and
then
the
cancer
controller
upgrades
you
know
the
defaulting
does
not
happen,
because
there
was
no
right
that
was
made
to
as
a
twister
and
now
when
the
capsicle
can
roll
up
twice
to
do
all
right.
It
just
fails.
D
And
the
fix
is
that
you
know
whenever
the
capsi
wants
to
update
Azure
posterior
object
as
part
of
the
reconciliation,
it
should
actually
put
the
right
value
for
the
back
and
pro
name.
That
is
basically
what
is
done
in
the
default
logic
of
image.
So
we
have
like
three
out
three
load
balances
back
into
name,
and
you
know
if
the
load
balancer
name
is
empty.
We
just
put
like
the
the
name
that
should
have
been
put
throughout
this
chain.
D
D
A
C
So
okay
looks
like
we
need
to
invert,
so
we
have
looks
like
we
have
existing
logic
which
detects
if
there's
no
load.
Basically,
we
assign
a
back
and
pool
name
based
on
load,
balancer
input
via
web
hook
right
so
now
we
need
to
invert
that
for
back
compat
scenarios,
so
the
load
balancer
name
needs
to
get
updated
to
match
the
new
backend
pool
name,
although
I
mean
I,
don't
know
if
that's
actually
going
to
work,
so
I
think
we
need
to
figure
out
a
way
to
identify.
D
Yeah
I'm,
trying
to
understand
completely
with
the
web
changes
that
are
there
will
not
help.
We
will
need
to
have
a
defensive
logic
and
capsic
controller
itself,
because,
let's
talk
about
when
this
change
was
not
there,
capsic
controller
neighbors
submitted
a
data
that
had
an
empty
backend
pool
name
now.
After
this
change,
there
can
be
a
situation
where
capsic
controller
submits
data
to
Azure
API.
That
has
an
empty
back
in
full
name
and
that's
where
it
fails
to
Azure
API
so
far,
it
makes
sense
that.
D
Yes,
nothing
has
changed,
yeah,
yes
and
as
part
of
a
great,
we
are
not
running
webwork
and
as
far
as
well.
Now
it's
no
it's
not
in
our
control,
because
the
webs
for
that
particular
object
will
only
trigger
their
say
right
on
that
object.
So
if
there
is
already
a
right
event
on
that
object,
then
all
it
will
trigger,
and
that
was
new
to
me.
A
A
D
C
Actually,
maybe
this
is
naive
of
me,
but
I'm
not
worried
about
it.
Making
sense
I
feel
an
intuitive
confidence
that
we
that
there's
a
fix
for
this,
so
take
that
for
what
it's
worth
so
no
I
don't
entirely
understand
what's
going
on
and
how
to
fix
it,
but
it
I
would
be
very
surprised
if
there's
not
a
fix
in
code
for
this,
and
if
we
have
to
like
revert
it
and
start
from
scratch
or
something
but
I
feel
like
these
types
of
changes.
C
We've
done
a
bunch
of
times
and
they're
they're
always
sort
of
nasty,
but
we
have
enough
patterns
in
place
that
we
should
be
able
to.
All
you
need
to
really
be
able
to
do
is
is
during
the
flow,
whether
it's
reconciliation
or
API
server
web
books.
You
need
to
be
able
to
identify
from
the
input
data
whether
or
not
you
are
in
a
sort
of
Legacy
scenario
or
or
you're
a
new
cluster
scenario
built
from
that
code
and
in
my
experience,
is
usually
a
way
to
do
that.
B
D
So
I
had
a
question
about
something
like
when
I
wanted
to
comment.
I
did
comment
to
them.
Github
went
down
so
yeah,
so
I
couldn't
comment
on
that.
So,
like
that
makes
sense,
we
could
move
out
to
a
separate
function
so
that
it
process
for
everybody.
But
do
we
want
to
like
support
for
the
versions
that
go
out
of
support
from
the
community,
because.
A
D
A
That's
a
great
question:
actually
we
haven't
defined
that
as
an
upgrade
policy.
I
think
Cappy
does
support
upgrade
from
any
version
as
long
as
it's
within
the
same
API
version
contract,
so
in
the
and
we
do
test
upgrade
like
so
we
have
an
upgrade
test
that
and
I
think
really
recently
added
that
as
he
removed
the
Viewmont
4v1
Alpha
3
code,
but
it's
building
a
cluster
from
cap
Z
and
cap
e1.0
and
then
upgrading
that
to
the
latest,
whatever
Branch
we're
testing
from
so
main
or
PR.
A
A
F
A
D
A
D
A
Yeah,
so
you'd
want
to
just
take
your
function.
I
think
like
what
you
have
is
correct.
It's
just
instead
of
saying
we're
going
to
remove
it.
You
know
once
people
have
upgraded
I
think
we
just
want
to
keep
that
somewhere
like
I.
The
reason
I
said,
move
it
out
is
just
that,
so
that
it's
cleaner.
That
way,
we
don't
have
to
do
it
every
reconcile
Loop.
We
just
do
it
once
and
then
for
the
future.
It's
it's
set
and
the
user
can
see
it
in
there.
It's
persisted
in
the
API.
D
So
when
I
move,
this
Anonymous
function
from
line
255
to
260
into
a
different
function,
the
home
for
that
function.
Is
this
file
or
the
actual
file
where
we
put
like
all
the
generator
and
getting
functions?
For
such
thing,
there
is
a
file
somewhere
else
that
says
yeah.
It
should
generate
them
and
stuff
like
that.
Yeah.
A
I
think
you
can
keep
it
in
this
file.
We
can
follow
up
async
on
the
PR,
but
like
yeah
I
would
change
it
to
instead
of
just
returning
just
setting
like
like.
If
this
is
empty,
then
set
this
to
that
makes
sense.
Okay,
we
can
I
can
follow
up
on
the
PR,
but
yeah.
Thank
you
for
for
doing
this,
and
then
do
you
want
to
talk
about
the
second
one,
because
there
are
two.
D
So
whenever
this
line
166
executes
whoever
complaints,
because
it's
an
immutable
thing,
so
what
we
need
to
do
is
we
may
we
need
to
Nuke
this
validate
accelerated
networking
block
from
developed
so
that
this
doesn't
complain.
I
have
also
outlined
this
in
the
issue
itself,
so
what's
happening,
if
you,
if
you
see
the
issue,
if
you
cannot
understand.
A
G
I
had
a
thought
about
this,
so
if
you
look
into
the
web
hooks,
while
doing
this
comparison
are
while
porting
over
the
subnet
name
in
accelerated
networking,
we
also
reset
the
subnet
name.
I
was
thinking
if
we
could
do
a
similar
logic
like
that,
where
we
Port
over
the
predefined
accelerated
networking
as
well
of
and
that
could
save
us
from
making
it
mutable
or
immutable
like
changing
the
behavior
of
a
webhook
I'm,
not
sure.
D
Got
it
so
step,
one
is
to
like
understand
the
issue,
and
then
we
can
come
to
solution.
I
just
raised
a
PR.
That
doesn't
mean
that
that
is
the
way
to
solve
it.
We
can
do
whatever
is
the
best
one.
So
if
you
see,
if
you
open
the
be
sure
to
say,
I
have
like
again
outline
if
you
go,
if
you
go
under
your
description,
I
mean
the
issue
itself.
It's
a
bit
of
LinkedIn
here.
D
A
Here,
yeah
yeah
one
question:
I
had
and
I
tried
to
comment
on
your
PR,
but
GitHub
was
also
not
letting
me
post
comments
at
some
points
right
before
the
office
hours,
so
I
don't
know
if
it
actually
posted
or
not
I.
Think
the
the
spirit
of
this
validation
is
to
make
sure
that
a
user
doesn't
change
the
value
of
accelerated
networking
after
the
cluster
is
created
because
it
can't
be
changed
right
right.
A
A
G
A
A
A
C
So
if
you
go
back
to
that
previous,
if
you
just
the
alt
tab
to
where
you
were
before
that
exactly
so,
it
looks
like
What's
Happening
Here.
Is
that
we're
literally
moving
the
value
of
accelerated
networking
from
one
object
to
another,
and
at
least
the
intention
was
like,
let's
clean
up
the
no
longer
used
property
value
on
the
old
object
by
setting
it
to
nil,
so
I
think,
if
that's
what
we're
going
to
do,
then
we
probably
just
need
to
update.
C
You
know,
user
updates,
so
everything
I
mean
I
think
this
is
just
a
good
point
of
guidance.
Everything
that
we're
actually
all
these
transitions
that
we're
doing
in
code
always
need
a
complementary
webhook
audit
to
make
sure
that
we're
not
subverting
what
the
webbook
expects.
Does
that
make
sense
what
I'm
saying
I
think
that
would
be
the
fix
for
this
is
simply
to
update
that
accelerated
networking
well
against
the
Azure
machine.
Spec
go
ahead.
D
C
D
So
maybe
I'll
need
to
test
it.
So
I
don't
know
like
so
I
might
thought
was
so
you
are
saying
that
we
write
some
code
in
webwork.
That
says
that
this
is
a
transition
just
allow
it
which
made
sense
it
does
possible.
We
should
do
that.
I
am
I'm
on
same
page
to
that,
but
just
I'm
thinking,
if
open
API
schema,
says
that
a
particular
field
is
immutable.
C
B
C
Thing:
that's
why
we
use
web
hooks
for
immutability
can
can
enforce
things
like
required,
so
it
won't
allow
the
field
to
have
the
zero
value,
whether
that's
an
empty
string
or
zero
or
nil.
But
I
think
that
the
point
is
that
a
change
like
system
was
just
describing
that
that
can
work
in
concert
with
web
hooks
when
we're
in
a
create
flow,
because
we're
doing
that
I
I,
guess
I'm
gonna
I,
don't
want
to
digress
I'm.
D
A
Cool
I
think
we're
all
talking,
I
think
we're
all
aligned
that
the
change
needs
to
happen
in
the
validation
web
hook.
It's
just
a
matter
of
what
we
allow,
what
we
don't
allow
yeah,
okay,
great
so
in
terms
of
the
patch
release
or,
first
of
all,
does
anyone
have
any
other
questions
or
comments
about
these
two
fixes.
D
C
I'll
say
one
more
thing:
I
I
think
there's
a
a
huddle
conversation
that
could
happen
around
that
no
knowing
out
of
the
old
value
I
think
there's
an
interesting
conversation
where
you
could
argue
that
that
was
the
wrong
or
the
more
dangerous
approach.
If
you're,
if
you're
evolving
the
spec
to
move
configuration
from
one
object
to
another,
you
could
argue
there's
an
argument.
You
made
that
that
having
like
additive
or
like
Superfluous
configuration
is
safer
for
forward
compatibility
than
that
kind
of
approach
where
we
nil
out
the
existing
value.
A
C
It
totally
makes
I'm
not
saying
the
only
argument
is
in
one
direction
or
the
other,
but
I
think
it's
it's
just
these
are
the
things
that
we
we
don't
not
have
to
think
about.
We
don't
have
the
option
to
not
think
about
these
things
because
we're
we're
in
this
world
where
we're
maintaining
a
continually
forward
moving
API.
C
A
A
A
C
C
Correct,
but
there
are
some
there's
a
there's,
a
sort
of
related
thing
we
have
to
do,
which
is
that
some
tests
need
one
nine
in
in
our
big
exploded
ecosystem.
So
we
need
to
be
thoughtful
about
the
test:
infrared
update
to
1
9
of
cap
C
and
essentially
audit
each
update
for
against
the
the
sort
of
question.
B
A
B
A
C
A
C
C
So
the
tests,
the
the
bugs
that
we've
been
talking
about,
are
I,
think
you
can
isolate
those
to
upgrade
scenarios,
and
so
none
of
these
Downstream
tests
that
we're
referring
to
that
need.
The
latest
bits
do
upgrade
tests,
and
so
they
should
be
safe
to
to
pin
to
one
nine
as
of
right
now
so
I
think
we
can
start
that
effort
right
away.
A
B
It's
it's
a
week
shorter
than
two
months
because
it
seemed
like
a
bad
idea
to
do
it.
The
next
week,
which
is
Fourth
of
July
and
then
I,
considered
extending
it
a
week,
but
I
thought
girl.
So
yeah
we
can
change
the
date.
I
just
picked
that
because
I
thought
Fourth
of
July
week
was
a
terrible
week
to
do
the
release.
A
A
E
A
A
A
If
anyone
has
things
that
they're
working
on
already
or
they
know
they're
going
to
be
working
on
in
the
next
two
months,
I
guess,
please
feel
free
to
go
ahead
and
add
them
to
the
Milestone
or
tag
me
or
one
of
us
to
edit.
If
you
don't
have
permissions,
but
in
the
meantime,
I
guess,
let's
just
check
in
for
now
for
today
on
those
that
are
already
in
the
Milestone
and
then
maybe
next
week
we
can
move
stuff
in.
Does
that
sound
good,
okay,
great,
so
I'll
just
quickly
go
over
them.
A
A
D
D
Yeah
keep
it
so
I
think
they
have
like
their
documents
from
Cecil
and
Niche
responded
to
your
Adam
I'm
on
to
incorporating
those
and
I
also
plan
to
kind
of
give
it
to
walk
through
of
that
next
week,
I
in
the
emergency
department,
so
that
it
helps
to
propose
to
review
so
I
think
work-wise.
It's
done
it's
mostly
late,
bringing
all
of
us
on
the
same
page,
yeah.
A
A
B
A
B
A
C
C
A
handle
on
exactly
what
the
distinction
is
between
the
two,
so
I
have
a
PR
that
has
a
whip
disclaimer
in
front
of
it.
So
that's
the
one
I'm
referring
to
that
I
think
should
go
into
110,
and
so
we
may
as
well
just
keep
both
of
these
in
110
and
then,
if
we
solve
only
one
or
the
other,
because
we
determine
that
they're
entirely.
Discrete
then
we'll
do
that
in
111,
I
guess:
okay,.
A
Sounds
good
add,
support
for
confidential
wins.
I
can
speak
to
that
I
think
we
can
keep
it
in
PR's
been
making
some
good
rounds
of
review
and
I
think
it's
close
to
ready
the
issue
with
that.
One
is
it's
hard
to
test,
but
that's
I
digress.
We
can
talk
about
that
in
the
pr
okay,
this
one's
mine
I
finally
got
the
images
available.
A
G
A
Yeah
I
think
it
makes
sense
for
us
to
keep
issues
in
the
Milestone
because
they
have
the
PRS
linked
to
them.
Anyways,
but
I
think
we've
been
kind
of
adding
both
so
yeah.
It
doesn't
really
matter
to
me,
but
if
someone
has
a
strong
opinion,
we
can
thank.
You.
Have
a
yeah
just
agree
on
a
process,
all
right
flight
card
tests
that
one
looks
like
it's
soon
to
merge
or
close
to
merge.
A
F
F
A
E
A
F
A
B
F
A
A
F
F
A
F
Yeah
sure
I
just
I
just
wanted
to
this
is
a
new
view
from
the
from
GitHub
on
this,
this
roadmap
View,
and
so
it's
obviously
not
comprehensive
with
what
we
have
there,
but
I
I.
Just
my
intention
was
to
have
something:
that's
kind
of
higher
level
kind
of
for
some
of
the
bigger
items
right,
because
it's
just
too
much
work
to
have
every
little
thing
there,
but
some
of
the
things
that
are
you
know
a
week
or
more
right,
large
extra
large
items.
F
You
know
to
put
those
in
there
and
then
kind
of
give
a
rough
idea
of
when
we
think
those
are
gonna
are
gonna
merge.
This
hasn't
been
updated
in
a
while.
So
you
know,
I
think
we
can
yeah,
that's
that
one's
really
large,
so
that
might
be
a
little
too
large
to
put
into
the
one
Milestone,
because
that's
the
Uber
issue,
but
some
of
the
sub
issues
might
would
be
probably
a
good
a
good
thing
to
put
in
and
so
I
think.
F
F
A
E
A
F
F
You
know
who
like
roughly
when,
if
it's
even
if
it's
a
month
or
two,
you
know
two
months
out
like
we
think
they'll
be
parallelization
available.
That
would
be
good
because
we
are
gating
a
lot
of
the
upgrade
stuff.
That's
that's.
A
growing
backlog
of
features
that
are
missing
from
the
manage
cluster
and
I
do
have
an
Uber
issue
on
that
as
well,
so
yeah
does
that
make
sense.
Yeah.
E
Yeah
and
and
I
think
there
are
some
like
smaller
opportunities
to
parallelize
other
things,
so
but
yeah
I'll
make
sure
to
clarify
any
issues
if
there
are
any
hard
dependencies
between
issues.
But
then,
if
there
aren't
any
listed,
then
I
think
it's
fair
to
assume
that
that's
free
to
pick
up
at
the
moment.
E
F
Yeah
so
I
think
I
think
if
we
just
put
a
little
more
like
conversion
of
some
of
the
issues
that
you're
currently
working
on
and
then
you
know
maybe
call
out
ones
that,
like
right
now,
for
instance,
could
be
have
someone
else
pick
them
up.
That
would
be
good
to
know,
and
then
that
way
we
have
an
opportunity
to
kind
of
make
things
go
a
little
a
little
faster
to
get
to
get
towards.
F
A
Sounds
good.
This
is
a
very
useful
thanks,
David
I'm
wondering,
should
we
try
to
do
some
backlog
grooming
with
this,
maybe
like
alternate
with
the
Milestone
planning
that
we
do
in
the
office
hours
so
like
right
now
we're
doing
Milestone
pretty
much
every
week,
which
yeah
I
think
every
two
weeks
would
be
enough,
and
then
we
could
alternate
and
do
kind
of
grooming.
F
A
B
F
F
F
F
A
F
So
yeah
I
didn't
have
the
ability
to
do
what
you
just
did
and
we
talked
about
that
already.
But
that's
okay,
it's
it's
complicated!
Because
of
what
permissions
you
have
to
give
me
and
all
that
but
yeah.
So
it's
it's
thinking,
but
I
think
it
was
105.
So
you
probably
have
to
do
another
batch
after
this
and
then
I
think
that
should
be
it
and
then
we
should
go
through
the
next
one
and
see
which
of
the
next
that
are
open
should
be
potentially
on
the
110.