►
From YouTube: [SIG-Network] Ingress NGINX meeting 20210817
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
B
C
E
A
We'll
we
can,
we
can
talk
about
it
later.
It's
one
of
the
issues
we
have
with
our
cloud,
build
it
always
when
the
cloud
fields
fails
90
of
the
time
it's
because
of
the
mainframe
build
anyway.
Thank
you
for
joining
and
we
look
forward
to
working
with
you.
Thank
you.
Anyone
else.
A
No,
all
right,
we
can
go
ahead
and
get
started.
We've
got,
I
think
we've
done.
I
I
did
a
bunch
of
triage
this
morning
and
it
looks
like
noah's,
got
a
lot
of
questions
for
us
to
go
through.
Really
we
don't
have
any
action
items.
I
would
think
that's
too
pressing
besides
v1,
which
is
our
first
one,
so
we
can
start
there
and
look
at
the
status.
We
can
pull
that
up.
You
ricardo!
F
F
Okay,
okay,
sounds
good
to
me,
so
yeah,
so
we
we
are
actually
on
on
some
some
sort
of
code
freeze
right
now,
but
we
we've
decided
in
the
channel.
I
was
talking
with
james
as
well
and
and
and
and
gentile,
and
so
we
decided
to
make
some
some
some
hard
stop
right
now
and
and
wait
for
people
to
test
if
you
want
a
better
helm,
shard
and
and
other
stuffs
and
also
while,
while
long
makes
the
documentation
about
the
migration,
I
think
we
are
almost
good
to
go.
F
I
I
can't
remember
any
other
show
stopper
issue
on
github
at
least
long
didn't
send
that
to
me
or
no
or
no
one
and
I
didn't
sell
as
well.
So
I
guess
we
are.
We
are
probably
good
to
go
and
I
am
just
waiting
so
we
can
discuss
if
we
are
gonna
merge
the
devious
branch
into
maine
or
if
we
just
wanna
rename
the
branches
between
like
maine
and
and
everyone
so
yeah.
We
should
probably
discuss
about
that.
F
But
if
you
ask
my
opinion,
I
guess
we
should
merge,
but
I
am
actually
really
good
at
breaking
stuff
at
git
and
making
and
making
like
the
github
complaint,
like
probably
microsoft,
should
hire
me
to
to
test
it
because
I'm
really
good
at
breaking
github.
So
I'm
willing
to
to
distance
your
opinion
as
well
about
merging
stuff.
F
A
I
was
gonna,
add
on
that's.
Why
that's
why
you
got
your
head
shaved
because
you're
getting
cleaned
up
for
the
interview
with
microsoft,
no
kidding
yeah,
I
I
haven't,
had
a
chance
to
review
long's
documentation.
Yet
I
was
looking
at
the
the
release
doc,
not
the
v1
migration
docs.
A
As
far
as
everyone
to
catch
everyone
else
up
to
speed
before
we
go.
I
guess,
then,
the
class
conflicts
probably
also
add
to
this
discussion
as
well.
So
before
we
talk
about
v1.
F
Yeah
yeah
yeah.
I
think
I
think
that
before
before
thinking
about
merging,
I
would
like
to
so
laszlo
sent
some
some
some
messages.
I
I
took
a
look
into
some
of
those
yesterday.
Oh
there's
nothing!
E
Yeah,
thank
you
and
thank
you
for
the
invitation,
so
yeah
so,
as
I
said,
I'm
from
ibm
cloud
kubernetes
service
and
we
provide
ingress
controllers
as
a
service
for
our
customers
and
so
far.
We
used,
of
course,
the
previous
versions
and
since
1.18
our
customers,
our
users,
use
the
ingress
class
feature
pretty
widely
as
well,
and
they
use
the
ingress
classes
according
to
the
how
to
say
current
rules
so
that
the
ingress
class
controller
field
is
a
is
a
static
mandatory
value,
pointing
always
to
the
same
value
and
the
ingress
classes.
E
As
I
understand
the
new
implementation
in
version,
one
would
use
the
ingress
class
controller
field
to
differentiate
between
the
ingress
classes
and
then
indirectly,
between
the
ingresses
among
the
english
controllers
and
as
I
tested
it,
I
found
that
users
who
would
like
to
upgrade
the
ingress
controller
in
a
how
to
say
canary
release
manner
or
so
actually
running,
two
ingress
controller
versions,
the
old
one
and
a
new
one
side
by
side
and
and
they
would
like
to
have
the
same
ingresses-
to
be
fed
into
both
ingress
controller
versions.
E
So
I
know
not:
every
user
wants
to
have
such
kind
of
seamless
upgrade
of
index
controllers,
but
there
are
users
who
would
like
to
run
the
new
ingress
controller
at
the
same
time,
on
the
same
cluster
with
the
older
one
and
in
case
of
problems
falling
back
to
the
older
ones.
So
they
I
I'm
sure
they
wouldn't
like
to
duplicate
their
ingress
amount,
resource
amount
and-
and
so
that's
it.
F
Okay,
so
I
am,
I
am
just
trying
to
just
to
be,
to
be
honest,
to
be
clear.
It
took
me
like
a
huge
amount
of
time
to
understand
as
well
the
like
the
ingress
class
and
how
they
have
changed
it,
and
I
also
made
some
complaints
with
with
rob
scott
and
the
other
folks
like
saying
hey,
so
you've
changed
this
and
yeah,
and
it
broke
a
lot
of
stuff
for
us
as
well,
and
he
said
yeah.
We
weren't
expecting
that
so
obviously
making
jokes,
but
it
was
pretty
pretty
hard
to
to
understand
that.
F
F
Specifically,
is
that
users
they
point
to
an
ingress
class,
but
you
might
have
like
a
lot
of
ingress
controllers
watching
the
same,
because
the
ingress
class
name,
actually
they
they
actually
can
be
like
they
point
to
a
spec
controller,
and
that
spec
controller
is
what
the
ingress
controllers
they
are
going
to.
Watch
right.
F
Yeah
yeah,
so
what
what
I
saw
that
juan
did
actually
is
you?
Can
you
can
specify
more
parameters
other
than
just
the
spec
controller?
So
you
can
say
hey.
This
is
the
blue
and
this
is
the
green
and
if
you
ask
some
feature
that
only
the
blue
ingress
controller
head,
it's
going
to
be
published
by
the
blue
one,
but
but
yeah.
This
is.
This
is
a
problem
I
I
I
need
to.
I
need
actually
to
make
some
some
further
tests,
but
do
we
know.
A
F
Yeah
yeah,
because,
as
far
as
I
remember,
this
is
like
this
is
actually
a
problem
of
this
is
actually
a
problem
of
how
ingress
class
was
developed.
F
It
was
like
concepted,
I
was
talking
also
with
alejandro
and
he
told
me
like
yeah,
so
I
saw
the
cap,
but
I
didn't
got
my
opinion
because
I
was
like
pretty
busy
and
when
it
got
married,
I
couldn't
say
anything
anymore.
So
I
was,
I
was
talking
with
him
as
well,
so
yeah.
What
what
we
can
do,
maybe
is.
I
don't
know
if
this
is
like
a
corner
case
or
not,
but
maybe
thinking
about
a
new
flag
or
something
like
that.
F
Just
as
a
capability,
let
me
say
some
way
of
easing
making
things
easier
right,
because
it's
not
it's
not
these
ingress
classes,
it's
not
easy
for
the
migration,
and
this
is
actually
why
I
am
like
asking
along-
and
I
am
making
some
reviews
about,
like
all
the
scenarios
and
how
users
can
migrate
because
for
the
90
of
the
users
is
mostly
like
hey.
F
G
You
ricardo
we
have
to
go.
G
We
have
to
have
a
very
clear
strategy
on
this
and
the
first,
the
top
priority
of
the
strategy,
even
before
the
specific
ingress
class
is
actually
splitting
the
documentation
and
our
stand
as
in
official
statement
on
users
who
are
not
on
1.22
and
who
are
on
1.22.
G
What
is
our
official
stand
on
people
who
will
who
wants
to
use
1.22
and
want
to
take
all
their
old
ingress
objects
to
1.22
and
then
comes
the
other
category
of
people
who
have
different
scenarios
with
not
being
on
1.22
different
controllers,
different
english
objects
and
then
the
actual
support
of
which
the
scope?
Actually
you
know
the
the
ingress
class
name
or
ingress
class,
whatever.
F
I
mean
like
the
majority
of
deployments.
They
are
simple
right,
it's
not
every
it's
not
like,
at
least
I
I
guess
it's
a
it's.
It's
a
guess.
Okay,
I
don't.
I
don't
have
like
numbers
about
that.
But
what
so
far,
what
I
can
see
is
like
the
majority
of
people
is
like
hey.
F
We,
we
want
to
use
an
egress,
and
this
is
like
the
one,
that's
official
official
one,
so
I
just
want
to
like
execute
like
a
city
of
applying
some
some
sort
of
deployment
script
and
have
everything
working
right,
but,
on
the
other
hand,
it's
it's
hard
because
we
have
like
the
the
cloud
providers
as
ibm
and
others
that
they
are
using
ingress
in
gynex
and
and
they
need
to
provide
a
way
for
their
users
to
migrate
as
well
so
yeah.
F
G
When
I
tried
to
document
only,
then
I
realized
that
there
is
one.
The
biggest
problem
is
the
actual
distinction
itself
and
what
is
the
official
statement
from
us?
For
example,
if
somebody
actually
starts
using
kubernetes
1.22,
they
have
no
option
left
but
to
install
v1
of
the
controller.
G
Yeah
currently
beta,
but
when
we
do
release
the
first
problem
and
the
first
answer
we
have
to
have
an
official
answer
is
what
are?
What
is
what
are?
What
is
the
official
documentation?
What
is
the
official
statement
saying
everybody
who
has
got
either
a
few
or
several
or
really
huge
number
of
ingress
objects
and
they
are
migrating
their
kubernetes
cluster
to
1.22?
G
So
if
you
think,
if
you,
if
we
are
talking
now
about
bringing
in
this
new
design
aspect-
that
we
try
to
give
them
a
flag
or
a
switch,
then
we
have
to
decide
that
now
or
as
soon
as
possible,
because
that
is
the
first
problem
I
mean
parallelly.
There
are
three
situations:
one
is
people
who
definitely
want
to
or
who
have
actually
moved
to
1.22
and
they
they
they
will
get
a
surprise.
G
F
Because
I
was
going
to
say
that
kubernetes
actually
have
this,
this
migration
contract
in
a
way
that,
if
you
migrate
from
116
to
118
and
from
118
to
120
the
objects
they
need
to
be
converted,
they
are,
they
are
actually
converted
in
in
in
by
the
by
the
admission
and
the
other
stuffs
right.
I
I
can't
remember,
but
I
saw
something
about
that
from
from
jordan
digit,
so
what
people
can't
do
actually
is
jump
from
116
to
122
right.
F
This
is
not
gonna
work
because
they
are
not
gonna
have
like
the
opportunity
to
migrate
their
object,
but
what
what
we,
what
they
can
do
is
actually
migrate
from
116
to
120,
I
guess
and
from
120
to
122
and-
and
they
want
me
to
like-
to
keep
removing
and
reading
the
objects.
I
guess
I
I
am
not
sure,
okay,
but
yeah.
I
think
that
one
thing
that
we
we
need
to
probably
make
some
statement.
F
Please
make
sure
your
you
test
your
migration
first
and
and
check
that
your
objects
are
working
because
from
from
the
viewer,
ingress
object
perspective
besides
ingress
class,
which
we
are
not
gonna
say,
but
we
have
like
three
major
changes
which
are
the
prefix
and
how
the
services
back
ends.
They
are
written
in
in
the
ingress
object
right.
So
it's
a
it's
the
surface
name
and
like
self
support
or
cersei,
whatever
courtney.
F
But
I
I
I
got
your
point
and
I
think
that
maybe
one
approach
that
we
could
do
is
hey.
We
are
releasing
this
for
krillinaris
version
122.,
but
we
still
don't.
I
saw
some
other
project
projects
doing
that,
so
we
still
don't
have
like
a
a
good
way
of
migrating
from
119
to
122..
So
we
just
don't
wanted
people
from
122
to
be
without
ingress,
and
this
is
why
we
actually
are
supporting
version
1
on
version
0.x,
but
we
are
going
in
this
window
to
figure
out
how
to
do
that.
Migration.
F
Maybe
okay!
I
don't
know
if
this
is
this,
I
I
really
don't
know
if
this
sounds
like
a
good
approach
or
if
this
sounds
like
hey,
we
just
wanna
jump
problems.
I
I
really
don't
want
to
jump
problems,
but
on
the
other
hand,
I
guess
we
need
to
make
this
release
happen,
because
we
already
have
people
running
like
on
kubernetes
122
and
they
don't
have
any
ingress
in
giants
to
run
there,
because
we
don't
have
any
official
universe
in
giants
to
run.
That.
G
And
they
changed
their
cluster
to
1.22,
then
we
are
forcing
them
to
re
to
to
switch
or
upgrade
their
ingress
controller
as
well,
but
normally
people
who
have
come
from
16
to
17
or
17
to
18
all
the
way
from
any
versions
all
the
way
up
to
21.
G
They
did
not
have
to
face
a
situation
where
they
had
to
change
their
ingress
controller,
so
anybody
who
comes
to
1.22
they
have
to
change
their
english
controller
and
that
message
we
have
to
basically
be
upfront
first
and
foremost,
so
I'm
basically
saying
these
different
scenarios
we
have
to,
we
haven't
gone
through
it
only
while
writing
and
trying
it
myself.
I
I
kind
of
felt
it
so
we
have
to
put
that
effort
and
kind
of
have
a
strategy
as
to.
A
Yeah,
let's
just
for
time's
sake,
because
I
know
we've
got
the
migration
dock
on
there
as
well,
and
we
we
can
circle
back
on
that
async.
We
have
to
have
the
scenario
plans
out,
but
let's
go
ahead
and
let
laszlo
present
his
issues.
The
only
other
thing
that
I
was
going
to
ask
is
laszlo:
do
we
have
this
documented
in
an
issue.
E
E
So
I
created
these
ingress
classes,
and
then
I
created
two
ingresses
enf
and
I
configured
them
with
the
different
english
classes,
and
it
had
the
thing
that
I
expected
happened
so
that
ingress
controller,
a
processed
ingress
e
because
of
the
english
class
definition
ingress,
controller
b,
processed
the
other
ingress
and
they
didn't
process
each
other's
thing
assist.
E
So
that's
that's
the
starting
position
where
a
user
is
currently
in
if
she
uses
ingress
classes
to
shard
ingress
is
among
english
controllers,
so
the
original
purpose
and
and
then
I
deployed
the
beta2,
a
version
of
the
one,
zero,
zero
ingress
controller
and
I
didn't
configure
a
controller
class
for
it
because
it
then
uses
this.
This
default
ingress
class
and
as
I
expected
it,
started,
processing
both
ingresses
existing
ingresses
because,
first
of
all,
the
new
ingress
controller
started
processing
the
english
classes.
E
It
found
it
it
matches
for
these
fields
from
now
on,
so
the
holding
rest
controller
mesh
for
the
name,
the
new
ingress
controller
matches
for
the
controller
and
because
the
two
ingress
class
has
the
same
controller
id
because
they
had
to
have
that
that
id
in
the
past.
So
the
new
ingress
controller
processes,
both
ingress
classes
as
its
own
and
from
that
point,
as
it
reads
the
list
is
lists.
Sorry
as
it
lists
all
the
ingresses,
it
will
process
all
the
ingresses
that
are
assigned
by
this
ingress
class
for
this
ingress
class.
E
I
will
find
that
that
the
single
deployment
that
I
deployed
with
version
one
processes,
all
my
ingresses,
which
is
not
sure
what
I
wanted,
because
maybe
a
ingress
controller
is
a
public
ingress
controller.
In
my
cluster
and
the
b
ingress
controller
is
privately
responsible
in
my
cluster
and
I
used
ingress
class
to
shard
investors
between
them.
E
But
now,
if
I
let's
say,
deploy
1.0
as
a
public
ingress
controller
behind
the
public
load
balancer,
then
suddenly
it
processes
all
the
is
how
if
I
don't
do
anything
if
I
don't
do
anything,
yes
and
what
I
found
the
logic
changed
so
that
as
but
I
that
I
said
that
so
far,
the
old
ingress
controller
used
the
metadata
name
for
everything
so
for
for
reading,
upping
rest
classes
and
for
matching
ingress
classes
with
ingresses.
E
E
It
runs
out
to
that
point-
that
the
user,
before
switching
on
a
new
english
controller,
has
to
create
new
ingress
classes
with
the
pointing
so
that
so
that
the
controllers
are
different
in
the
english
classes
and
because
there's
a
new
ingress
classes
and
not
namespaced
objects
or
whatever,
then
the
name
must
be
also
different.
Now,
if
the
name
is
different
in
the
ingress
class,
then
the
relevant
ingresses
must
be,
let's
say,
updated
as
well
with
the
new
name
of
the
interest
class.
E
E
Then
I
have
to
have
two
ingresses
now,
one
with
the
old
ingress
class,
one
with
the
new
ingress
class.
So
I
have
to
duplicate
my
english
resources.
Actually
in
my
cluster
for
this
purpose,.
F
F
Why
can't
you
get
your
ingress
object
and
say
hey
so
now
this
uses
ingress
class
d,
which
points
to
spec
dot
controller
arcades
that
I
owe
slash
ingress
dash
in
gynex2
on
your
ingredients
in
gynex
2,
for
example,
is
watching
that
one.
I
just
don't
get
this
one
this.
This
statement.
E
So
the
the
base
situation
is
that
I
want
to
keep
the
old
ingress
controller
running
on
the
cluster.
E
While
I
deployed
a
new
one,
so
I
must
keep
these
ones
as
they
are
and
at
the
same
time
I
would
like
to
start
up
a
new
ingress
controller
for
the
upgrade
of
purpose,
and
as
soon
as
I
start
this
one
and
I
don't
create
new
english
classes,
then
the
new
one
will
process
all
the
ingress
that
I
don't
want
in
order
to
sharp
ingress
is
for
the
new
ingress
controller
as
well.
I
have
to
create
new
ingress
classes.
There.
F
Okay,
yeah,
I
got
your
point
nice,
so
so,
if,
if
we
decide
here
to
create
something
like
sorry
james,
I'm
just
gonna
like
we
decided
to
create
something
like
a
configuration
called
a
legacy,
ingress
class
behavior
that
says
that,
instead
of
watching
the
ingress
class
controller,
spec
controller,
we
are
gonna
watch
the
name
and
like
this
have
some
caveats.
This
goes
against
like
why
ingress
class
was
designed,
but
actually
I
I
don't
care
right.
So
I
wanna.
E
A
I
I
would
think
if
I'm
wanting
to
test
new
functionality,
I'd
be
doing
it
in
a
lower
environment
before
I'm
deploying
it
to
my
production
clusters.
So
if
we
give
them
a
migration
path
of
I
I
I
don't
know,
I
wouldn't
want
to
do
both
in
the
same
cluster.
Especially
are
we
talking
about
from
like
a
migration
for
a
cut
over.
F
It's
I
I
I
got
his
point
james
like
in
in
some
some
cases.
That's
that's
in
place
migration
right,
so
you
can't
like
create
a
new
cluster
and
and
start
yeah.
F
So
so
so
for
laszlo
case,
for
example,
you
would
need
to
migrate
like
from
116
to
121,
which
supports
v1,
beta1
and
v1
and
run
like
ingress
in
genex
version,
0.x
and
version
1.
and
just
start
like
migrating.
The
ingress
objects
from
ingress
class,
a
to
ingress
class
b,
but
yeah
I
got.
I
got
your
point,
okay
yeah,
so
so
my
question
is:
if
we
specify
actually
let
just
being
honest
like
we,
we
knew
that
this
migration
wouldn't
be
as
soft
as
as
it
looked
right.
F
So
so
we
we've
got
like
90
percent
of
people
covered
by
hey
this
is
we
we
added
a
lot
of
flags,
but
we
knew
that
some
in
some
moment
these,
like
edge
cases,
were
going
to
appear.
So
this
is
why
I
asked
it
like
if
we
create
some
some
way
to
make
like
ingress,
v1
behave
as
ingress
version
0.x,
but
not
break
the
way.
So
it's
up
to
the
like
the
cluster
admin
to
say
hey.
F
A
Yeah,
I
I
don't,
I'm
not
a
fan
of
introducing
old
functionality
into
the
new
version
to
fix
an
issue
that
other
ingresses
are
going
to
have
as
well.
I
think
we
should
open
the
issue
and
contact
and
have
a
discussion
with
the
google
proxy
google
and
h.a
proxy
and
figure
out
how
they're
doing
their
migration
strategy,
because
I
I
don't
know
if
introducing
old
functionality
into
the
new
one
is
the
right
answer.
It
is
an
answer
I
don't
know
if
it's
the
right
answer
is
that
favorite
cardo.
F
Yeah
yeah
yeah,
so
what
I?
What
I've
seen
from
from
h8
proxy
is
that
they
are
doing.
Let
me
let
me
open
here
so
what
they
did
actually
is
they
support
the
old
behavior
before
the
new
behavior
right,
so
they
say,
hey
you
might
have
like
annotations
came
first
before
before
the
ingress
class.
F
So
if
you
have
english
class
and
annotation
I'm
gonna,
take
I'm
gonna
use
annotation,
first
and
inverse
class
later
right,
because,
okay,
we
already
support
yeah,
we
already
support
annotations,
but
but
but
on
the
order
of
the
store
we
first
figure
out
if
the
annotation
came
first
and
then
the
ingress
class.
F
So
this
is
like
on
a
strategy.
As
far
as
far
as
we
say:
hey,
we
are
not
going
to
support
annotations
in
the
future,
so
we
are
leaving
this
just
for
migrations,
but
yeah.
I
think
we
should.
I
think
we
should
document
that
I
just
don't
wanna
like
leave
users
with
problems
without
an
answer
right.
So
this
this
is
yeah.
This
is
like
the
way
they
design
the
ingress
class.
I
mean.
Fortunately
this
is
like
we
need
to
follow.
F
We
need
to
follow
that,
but
but,
on
the
other
hand,
kubernetes
have
this
contract
of
not
breaking
stuff,
and
I
guess
we
we
should
have
this
contract
as
well,
at
least
like.
While
you
have
the
opportunity
of
doing
migration
so
yeah,
probably
we
should.
We
should
document
everything
in
an
issue
and
discuss
on
that
and
say
hey.
This
approach
is
better.
That
approach
is
better,
hey,
that's
a
well-known
issue,
so
people
migrating
in
this
specific
case.
Please
take
a
look
and
follow
this
issue
and
don't
migrate
to
review
version.
F
A
F
A
Well,
awesome:
okay,
we're
42,
so
we're
probably
not
going
to
be
able
to
get
through.
All
of
these
do
we
want
to
go?
I've
done
a
review
already
of
the
the
release
that
you
put
out
long.
I
put
in
a
bunch
of
comments
to
the
update.
Did
anybody
else
get
a
chance
to
read
through
this,
because
I
know
we
had
some
growing
pains
with
the
old
way
of
doing
our
release
with
long,
so
he
was
able
to
go
through
and
did
a
bunch
of
updates
to
our
release.
A
A
F
A
Okay,
well
me,
and
you
have
done
the
most
releases
on
to
make
sure
that
you
saw
it,
but
I've
got
some
things
in
there
for
long
to
look
through.
Some
updates
just
make
a
little
bit
cleaner
because
some
of
the
things
are
redundant
and
I
think
my
big
thing
was
the
nginx
image
needs
to
be
pushed
with
the
rest
of
the
other
images
because
they
all
get
changed.
A
The
same
way
add
the
new
image,
because
there
was
one
for
the
web
hook
web
at
mission
hook,
so
the
cert
gen
I
forget
which
one
it
was
that's
a
new
image
that
we're
tracking,
because
the
first
step
should
always
be
a
merge
request
or
put
a
pr,
because
that's
going
to
kick
off
the
cloud
build
and
that's
going
to
give
us
the
new
shaw.
That's
always
our
first
step.
The
other
ones
are
optional,
because
otherwise
you
just
jump
to
step
four.
So
I'm
trying
to
make
it
a
little
bit
more
logical
from
that
respect.
A
So
as
long
as
you
have
any
questions.
G
No,
I
saw
your
comments
I'll
make
the
change
as
soon
as
possible,
probably
after
this
meeting
I'll
make
those
changes
and.
A
A
Okay,
that's
all
I
have
for
that.
That's
a
pretty
quick
one.
We
can
go
ahead
and
get
started.
No
you've
got
a
bunch
of
issues
for
us
to
look
at
so
I
thank
you
for
going
through
all
of
those.
I
know
that
that
can
be
a
flawed,
sometimes.
G
Yeah,
even
if
it
is
bad,
even
if
it
is
not
so
up
to
date,
something
we
have
to,
we
have
to
put
up
something.
F
I'm
not
gonna,
I'm
not
gonna
review
today,
because
I
I
my
agenda
is
pretty
busy
today,
but
I
will
make
my
biggest
effort
to
review
your
document
again
tomorrow
and
and
say
if
we
are
good
to
go
or
not
or
if
we
can
like
at
least
let
go
with
the
document,
the
way
it
is
for
tomorrow
and
and
leave
some
follow-ups
for
people
to
fix
that
okay,
yeah.
A
A
Okay:
let's
go
ahead
and
get
started.
I
know
we've
got
we're
short
on
time,
but
let's
go
ahead
and
start
looking
at
the
features
that
noah's
pointed
out.
That's
not
the
first
one.
F
Yeah,
so
for
this
one
specifically,
I
don't
have
opinion.
Actually,
I
know
that
a
lot
of
people
is
actually
dumping
up.
This
I
just
need,
what's
the
impact
for
like
for
monitoring
for
other,
for
the
performance
of
of
this
lua
back
end
as
well
generating
those
information.
But
so
if
someone
wants
to
take
a
look
and
say
hey,
the
bucket
thing
makes
sense.
F
I
am
okay
that
we
can
take
a
look
a
better
look.
I
saw
on
past
another
issue
that
chris
luciano
actually
was
taking
a
look
and
he
told
he
he
wrote
something
like
hey
this
book.
This
bucket
histogram
is
pretty
spread,
or
something
like
that.
So
I
didn't
had
any
opinion
about
that.
So
maybe
folks
more
familiar
with
prometheus
instagram
and
can
give
some
opinions
about
that.
F
F
Yeah,
I
just
changed
the
branch
and
make
that
that
yeah,
okay.
Okay,
if
someone
want
to
take
a
look.
A
C
G
C
A
F
If
you
do
yeah
a
life
cycle,
slash
life
cycle,
yeah.
F
Space
accepted
life
cycle
active.
F
G
I
will
look
at
the
prometheus,
histogram
thing
and
I'll
comment
on
it
boom.
Can
you.
E
A
Revocation
list
they
were,
I
think
one
someone
was
looking
at
trying
to
move
it
to
a
a
config
map.
Another.
F
F
I
understand
the
problem,
because
the
certificates
revocation
list
they
can
grow
up
a
lot
actually
really
a
lot,
but
on
the
other
hand
we
yeah,
we
can,
we
can
add,
like
a
triage
accepted
or
at
least
like
a
life
cycle,
priority
backlog
and
take
a
look
later
because
it
makes
sense,
but
we
need
to
think
in
another
way
of
dealing
with
crl,
for
example
crl
they
are
deprecated
in
like
go.
Libraries
and
people
keep
asking
for
like
certificate
authorities
to
use
ocsp
so.
B
F
C
A
A
F
A
56,
we
should
have
time
for
a
couple
more
a
documentation
issue.
It
was
always
fun.
F
F
Yeah
yeah,
that's
that's
carlos,
so
I
I
have
a
meeting
with
him
tomorrow
and
he
wants
also
to
make
some
some
sync
about
ingress
in
china.
So
I
can
talk
with
him
tomorrow
about
like
he.
He
actually
he
takes
a
look
into
everything.
Carlos
is
all
around
the
internet.
You
feel
like.
If
you
look
into
a
repo,
you
are
gonna,
see
his
avatar,
so
I'm
gonna,
I'm
gonna
talk
with
him.
He
told
me
that
he's
trying
to
sink
as
well.
F
Yeah
this
is
on
me.
I
guess
this
is
on
me
and
jintao.