►
From YouTube: Contour Community Meeting - May 5, 2020
Description
May 5, 2020
What have we been working on?
Bugs in 1.4:
2481, fixed in 2482
2483
New GitHub label schema
Issue discussion
2495 Richer status
Contributor Shoutouts
2480 thanks @savithruml
Demo/Presentations
Kubernetes VMware User Group meeting: Contour/Gimbal in on-Premise environments (Thursday 5/7/20 @ 11am PST)
A
Hi
everyone
and
welcome
to
this
week's
community.
A
contour
community
meeting
today
is
May
5th
or
may
6,
depending
on
where
you
live
and
per
usual,
we
get
a
bunch
of
things
that
we
want
to
go
over
today.
We've
got
some
status
updates.
We've
got
some
issue
discussions
if
you
want
to
add
something
to
the
meeting
notes.
A
If
you
want
to
discuss
something
or
have
something
that
you
want
to
bring
up,
you
can
add
them
to
the
mean
meaning
notes
or
just
speak
up
as
well,
that
works
too,
and
with
that
I'm
gonna
share
my
screen.
So
you
all
can
see
the
agenda
for
today
all
right.
The
first
things
is,
of
course,
what
have
we
been
working
on?
Nick
yeah.
B
So
a
couple
of
the
important
bugs
that
we
found
soon
after
a
1.4
came
out.
The
ingress
status
updating
was
that
we
missed
mister
thing
where,
if
you
set
an
ingress
class,
the
status
updating
that
wasn't
contour
than
the
status
updating,
wouldn't
work
classic
testing
failure,
so
yeah
it
was
pretty
easy
to
fix,
though,
and
there's
a
fixed
already
merged
for
it.
So
yeah.
Thank
you
to
see
ten
for
reporting
that
one
and
was
yeah.
C
D
D
D
But
people
have
reported
that
in
the
past,
based
on
the
TLS
passed
through,
because
they
can
be
ambiguity
at
the
envelope
filter
chain
level.
But
what
happens
now
that
we
in
1.4,
we
landed
basically
strong
sni
bindings?
Everyone
who
is
using
wildcards
is
going
to
hit
this
too.
So
you
imagine,
you
have
a
set
of
s.
A
nice
set
of
server
names
and
each
server
name
has
only
the
routes
for
that
server.
So
the
server
name
you
ask
for
it
a
client.
It
gets
exactly
the
routes
for
that
server
name.
D
B
B
It
isn't
like
it's
effectively
an
envoy
bug
all
my
blood,
pretty
much
that
it's
not
that
it
doesn't
I
mean
it's
a
bit
debatable
whether
it's
a
bug,
but
it's
definitely
at
least
a
mist
feature
that
it
doesn't
allow
you
to
do
this
in
some
way,
and
so
we
would
like
to
sort
of
get
upstream
on
where
to
do
that.
Yeah.
D
It's
kind
of
an
over
its
kovin
oversight.
It
would
be
nice
for
it
to
be
kind
of
natively
supported
in
some
I.
Think
logistics
of
that
are
sort
of
gonna
be
interesting,
because
I
suppose
we'll
also
need
a
discussion
with
the
Envoy
maintain
is
if
we're
gonna
push
a
fix
for
it,
and
we
would
also
want
to
discuss
with
you
on
by
maintains
whether
it
goes
where
the
fix
goes
into
the
v2
or
the
v3
API
and.
B
So
yes,
that's
another
thing
to
note,
for
everybody
is
that
envoys
API
deprecation
policy
is
now
like
very
aggressive,
so
it's
once
per
year,
they
will
do
a
major
Rev
of
the
ACS
api's,
and
so
the
XDS
api's
will
only
live
for
two
years
from
go
to
whoa.
So
yeah
we're
good
you.
We
need
to
make
sure
that
we
keep
on
top
of
that
so
yeah.
This
one
is
pretty
important.
B
The
main
point
I
wanted
to
raise
here,
though,
is
that,
although
in
this
case
in
this
specific
instance
we're
using
a
little
filter
to
fix
the
thing,
I
just
wanted
to
be
very
clear
that
this
doesn't
mean
that
we're
going
to
be
adding
anything
that
lets.
You
configure
your
own
little
filters
in
there
in
the
near
future.
Just
wanted
to
make
that
100
percent,
clear
and
I
think.
D
B
D
B
Yeah,
okay,
well,
while
you're
changing
that
we
can
probably
move
on
I.
Think
we've
covered
that
one
pretty
well.
The
yeah
I've
got
a
sorry.
I'm
gonna
put
a
link
in
there
too,
to
2480.
Thank
you
yeah.
So
this
was.
This
is
a
PR
from
survey
through.
Thank
you,
so
they
threw
on
the
call,
but
yet
but
yeah.
Thank
you
diem
for
just
finding
a
finding
finding
a
problem
with
the
docks
and
pran
fix.
B
B
D
Sure
I
think
I
don't
have
a
lot
of
the
history
around.
You
know
the
good
had
labels,
but
there's
there's
a
couple
of
issues
that
I
wanted
to
try
and
address
with
this.
Firstly,
as
the
project
has
more
repos
now
than
it
has
done
in
the
past,
so
I
feel
that
it
would
be
good
for
us
to
have
like
a
a
consistent
grammar
or
a
schema
of
labels
across
all
the
repos
in
the
project
contour
project.
D
The
second
thing
is
kind
of
I
think
they
you
know.
A
lot
of
the
labels
grew
organically
as
people
needed
them
for
different
projects.
So
I
wanted
to
kind
of
consolidate
this
into
a
single
place
where
which,
where
we
could
document,
you
know,
you
know
public
way
what
we
expect
the
labels,
what
meaning
we
think
the
labels
has,
and
you
know
maybe
talk
about
how
we
use
them.
The
schema
is
general.
D
The
schema
generally
follows:
kubernetes
labels
schema
project
labels
because
I
think
most
of
the
people
in
the
maintainer
group
and
contour
community
are
going
to
be
heavily
seen
and
have
some
familiarity
with
that.
Kubernetes
schema
we
I
kind
of
expect
the
schema
to
change
a
bit
over
time.
You
know
I
think
it's
one
of
those
things
where
you
know
the
change
is
a
good
thing,
because
we
want
to.
We
want
the
label
schema
to
reflect
what
we're
actually
doing.
B
Thanks
James
yeah
I
I've
already
started
making
sure
that
we
set
those
said:
there's
life
cycle
ones
as
soon
as
we
have
a
look
at
a
ticket,
even
if
we
just
put
life
cycle
investigating
it's
a
nice
signal
to
everybody
that
yes,
we've
seen
the
ticket
than
we're
interested
in
looking
at
it
more
cool,
well,
I
think
we'll
go
on
to
I.
Just
wanted
to
quickly
run
through
an
issue,
but
Steve.
Do
you
want
to
talk
about
your
arm
demo?
First.
G
Sure
we
can
so
I
got
asked
to
do
a
there's-
nothing
much
here
on
this
page,
but
there's
a
VMware,
a
user's
group.
So
it's
it's
one
of
the
kubernetes
IG's,
so
I
think
it's
for
folks
that
use
VMware
technologies
with
kubernetes,
so
I'm
gonna
chat
a
little
bit
more
at
least
I'm
trying
to
build
it
out
now
of
how
we
can
deploy
some
things
like
contour
and
gimbal
to
on-premise
environments,
so
like
very
metal
kind
of
places.
G
So
you,
how
can
we
brought
traffic
the
different
clusters
different
places
that
sort
of
things
so
I'm
gonna,
try
and
leverage
comment?
Obviously,
leverage
contour,
but
also
gonna,
do
some
things
with
Kimball
as
well,
I
think
to
help
brought
some
things
around.
So
that's
all
I
come
up
with
so
far.
The
talk
is
on
Thursday
at
11:00
Pacific.
So,
if
anyone's
interested
come
stop
by
I
think
that
the
link
is
he's
here
for
the
there's,
a
meeting
and
stuff
I'm
sure
to
be
recorded
and.
H
And
the
biggest
thing
by
the
way-
and
thank
you
Steve
for
for
for
driving
this-
is
that
noise,
as
a
lot
of
customers,
are
playing
around
with
this
cloud
native
ecosystem
and
space,
but
they
still
have
a
lot
of
apps
in
VMs.
So
it's
gonna,
be
you
know
every
Enterprise
customer
there
has
hybrid
installations
when
it's
hybrid
I
mean
some
VM.
Some
containers
and
they're
gonna
need
traffic
and
the
connection
between
all
of
those
components.
So
control
can
play
the
role
by
helping
kind
of
bridge
that
gap.
H
D
B
Okay,
so
yeah
I
wanted
to
talk
a
little
bit
about
self-interested
yet,
but
this
is
an
issue
that
I
raised
this
one
is
this
one
is
I've
raised
this
one,
because
I
think
this
is
this
is
blocking
a
whole
bunch
of
other
features
that
would
we'd
all
really
like
to
work
on
amongst
them.
Being
you
know,
things
like
echo
or
I
think
the
rate-limiting,
maybe
even
the
tracing
as
well.
B
One
of
the
things
that
I
I
feel
pretty
strongly
about
is
that
contour
should,
if
want
to
accept
config
contour,
should
make
information
about
that
config
available
to
the
to
the
user.
Who
could
forget
it
right
now?
A
lot
of
that
is
done
should
be
done
on
a
per
HTTP
proxy
basis.
So
you
know
if
you've
configured
something
a
feature
on
HTTP
proxy.
You
should
be
able
to
see
from
your
HTTP
proxy.
You
know
that
the
feature
that
your
configured
is
working
you
should
be.
You
should
go
to
tell
maybe
there's
a
thing
there.
B
Maybe
there's
something
there
that
told
you
about
it.
Maybe
there's
something
else
you
know,
but
that
basically
we
need
a
lot
more
information
in
the
HTTP
proxy
status
stands
up
about
what
the
hash
typically
is
doing.
So
there's
a
couple
things
I've
gotten
in
flight
right
now.
To
do
this
see.
I
DS
now
can
have
a
stat,
what's
called
a
status
sub
resource
which
the
same
as
a
lot
of
the
other
kunas
core
objects.
B
What
that
means
is
that
when
you
update
the
part
of
the
object,
that
is
the
status
part,
it
requires
actually
using
a
different
rest
endpoint
on
the
Kuban
any
side.
To
actually
do
that.
The
other.
The
other
thing
that
that
means
is
that
if
you
push
a
yam
all
that
holds
the
object
if
it
includes
any
information
in
the
status
stanza
that
status,
that
information
is
silently
discarded.
B
So
there
is
a
bit
of
a
behavior
change
there,
but
the
the
idea
being
that
the
access
to
can
access
to
update
the
status
is
controlled
separately
from
access
to
to
actually
create
a
spec
and
with
the
idea
that
you
know
a
controller
in
this
case,
contour
should
be,
should
be
the
thing.
That's
updating
the
status
and
only
that
should
be
absolutely
status.
B
You
shouldn't
use
en
user
shouldn't,
be
a
Latasha
status,
there's
a
pretty
common
pattern
in
kubernetes,
but
and
in
the
past
we
hadn't
done
because
when
I
tried
to
do
it
initially
with
HTTP
proxy,
it
broke
some
things.
So
this
time,
I've
gone
back
and
there's
a
PR
up
to
to
enable
this
James
had
some
comments
on
it
Olga's
those
today,
so
we
should
be
able
to
get
that
any
pretty
soon.
B
I
have
considered
doing
something
different
here,
but
I
think
that
this
is
close
enough
to
a
a
ecosystem
wide
standard.
Now
that
that
it's
probably
just
it's
not
worth
for
reinventing
the
wheel,
so
that's
also
entrainer
I've
got
PR
halfway
done
to
do
that.
It's
not
all
that
hard,
although
there
might
be
some
refactoring
involved.
So
those
are
the
easy
bits.
The
harder
bits
are,
we
need
to
have
a
what
have
a
general
way
to
expose
this
status
information
on
HTTP
proxy
and
have
it
be
an
extensible
way
to
do
it
now?
B
The
way
that
you
do
that
the
sort
of
the
API
standard
way
to
do
that
is
to
use
a
list,
an
array
of
conditions,
conditions
are
a
type,
that's
there's
sort
of
a
like
a
subclass
type.
You
know,
so
the
condition
has
to
have
a
couple
of
properties
and
yeah.
It's
kind
of
like
it's
basically
essentially
like
a
go
interface
with
a
little
bit
extra,
and
so
you
can
say
is
you
know?
Basically
the
way
you
do
it
and
go?
B
Is
that
you
define
this
thing
as
a
require
as
being
a
slice
of
interfaces,
and
then
you
make
sure
that
the
that
the
condition
that
you,
the
conditions
you
add
all
fulfill
that
interface
and
then
you
can
extend
the
conditions
with
additional
fields
by
creating
your
own
special
conditions.
So
the
idea
here
is
that
I
I'm
gonna
add
a
slice
of
conditions
to
the
status
sensor
of
the
of
the
HTTP
proxy
and
then
start
thinking
about
what
special
conditions
we
can
add
to
cover
some
of
the
things
that
we
need
to
do
now.
B
This
blocks.
As
you
can
see,
it
blocks
a
lot
of
issues
because
and
that's
because
we
did
for
a
while.
We've
had
a
big
bucket
of
things
that
were
hey,
we
need
to
fix
status
and
you
know
to
be
able
to
be
able
to
do
these
things,
and
so
I
had
a
previous
crack
at
that
before
I
knew
about
conditions
that
was
way
too
complicated,
and
so
yeah
I
really
want
to
I
want
to
have
a
think
about
some
of
the
things
that
I
thought
about
there.
B
Some
of
the
other
features
that
we
need
and
make
sure
that
the
thing
that
we
put
in
the
way
that
we
put
the
conditions
in
is
sort
of
conforms
to
the
API
standards
and,
at
the
same
time,
is
extensible
enough
that
we
can
add
all
the
information
we
need
to
say.
Yeah,
that's
I
just
wanted
to
talk
through
a
little
bit
what
I
was
doing
here
and
then
your
in
case.
Anyone
in
the
community
had
questions
about
it.
B
D
B
Conditions
for
his
favor
so
ya,
see
yes.
I
am
very
much
aware
of
the
obviously
of
the
discussion
about
condition.
Polarity
that
came
out
of
services
API,
so
it'll
be
something
that
I
think
about
I'm
talking
to
the
K
native
guys
about
what
they
did
around
dark
lighting
conditions
to
see.
If
we
can
do
something,
that's
a.
B
D
And
my
first
I
think
they
had
okay,
let
me
run
and
untangle
my
tongue
I
think
this
is
great.
I'm
super
in
favor,
my
only
there's
the
Kip,
which
attempts
to
standardize
the
condition
struct.
So
we
should
have
a
look
at
that
and
see
if
we
can
I,
don't
know
if
we
can
adopt
that
directly
or
just
you
know,
copy
paste
or
something
yes,.
B
So
the
problem
there
is
that
looks
like
some
members
of
cigar
CH
I
like
yet
conditions
should
be
having
conditions
to
be
positive.
Polarity
makes
sense.
That
should
be
the
new
recommendation.
Other
members
of
cigars,
like
no,
no,
no,
we
design
conditions
to
be
to
be
negative
polarity.
They
should
own.
A
presence
of
a
condition
should
indicate
an
on
wanted
state,
and
so
there's
a
lot
of
philosophical
discussion
there
about
like
what
conditions
are
actually
supposed
to
be
for
so.
B
D
B
G
B
B
You
just
need
to
sort
of
set
out
the
contract
and
water
condition
is,
and
then
you
can
add
in
whatever
conditions
you
like
and
decide
on
the
behavior
of
those
conditions,
as
you
as
you
sort
of
add
in
the
behavior,
that's
the
that
is
literally
the
reason
why
conditions
are
there
is
because
people
were
finding
it
too
hard
to
you
know.
If
you
put
fields
in
then
you
can't
change
their
name
or
you
know
do
that
because
of
a
guy
guarantees,
so
a
slice
of
conditions.
B
G
I
think
so
I
was
just
more
of
figuring
out
like,
though
the
what
so
we
don't
it's
weak,
because
you
still
need
to
have
some
thought
around
what
you'd
want
to
put
in
there
I
think
so
we
don't
get
redundant
or
get
you
know,
I,
don't
know
yeah,
which
is
not
super
easy,
but
yeah.
There's
lots
of
things
that
we
could
probably
pick
out,
which
would
be
interesting
for
various
folks
in
terms
of
what
what
they
want
to
get
out
of
the
system.
Yeah.
B
Yeah
so
I
mean
I
think
the
first,
the
first
things
that
I
was
thinking
of
were
things
like
what
we
talked
about
earlier
in
the
previous,
my
previous
attempt
at
doing
something
about
status
and
stuff
that
you
raised
before
things
like
what
what
conditions
have
been
delegated
to
me
and
by
that
I
mean
routing
conditions,
not
status
conditions.
We
made
a
bad
naming
choice
there
and,
unfortunately,
because
we
didn't
know
about
status
conditions
at
the
time.
So
now
we
have
routing
conditions
and
status
conditions,
but
yeah.
B
D
B
Yeah
so
I
think
going
for.
We
can't
remove
that.
That's
part
of
the
rerun
contract,
the
I
I,
expect
that
that
will
effectively
be
a
rollup,
be
essentially
the
same
thing
as
a
roll-up
condition.
Where
you
know
it's,
it's
a
Sun
blade
across
all
of
the
conditions.
Some
of
them
might
be
warning.
Some
of
them
are
the
errors.
If
there's,
if
there's
one
or
more
error
conditions
that
in
render
the
that
render
the
thing
not
valid,
then
that
and
that's
the
field
will
be
set
to
valid
or
valid
in,
like
as
it
is
now.
E
B
B
It
looks
like
maybe
we
can
cube
kettle
can
already
wait
on
conditions.
So
if
we,
if
we
can
you'll,
be
able
to
wait
on
any
of
those
conditions,
hopefully
I'm
gonna
spend
a
little
bit
of
time
playing
about
once.
I
actually
add
two
conditions.
Obviously,
that
all
needs
to
happen
before
I
can
try
it
out.
D
B
B
A
D
A
D
A
B
C
A
C
Thing
I'd
mentioned
I,
don't
remember
the
exact
details.
I
remember.
We
did
see
some
some
issues
with
client
compliance
with
I
think
it
was
the
HTTP
to
go
away
response.
Your
thing
HT
to
be
four
to
one,
just
a
warning
that
may
not
be
respected
by
all
clients.
So
even
that
may
not
be
a
perfect
workaround.
We
ended
up
there
saying
if
you're,
using
the
same
certificate
certificate
you
have
to
assume
you
may
be
coalesced,
and
so
we've
we've
been
saying
you
have
to
use
your
own
specific
certificate.
D
B
D
B
B
Right
yeah,
so
yeah
we're
very
interested
in
in
everyone's
feedback
on
that
one.
That's
one
of
the
big
features
that
we're
looking
to
land
soon,
I've
also
got
I've
also
got
this
kind
of
state
of
contour,
which
I
come
to
as
landscape
I'm,
calling
it
blog
post
in
the
works.
That's
kind
of
talking
a
little
bit
about
where
contours
at
and
where
we're
gonna
be
going
from
here.
A
H
Usually
sincere
since
EF
does,
is
they
vote
internally,
so
they
don't
all
agree
and
then
they've
all
externally
to
show
everybody
that
they
voted.
So
if
the
internal
vote
doesn't
come
out
good,
then
you
know-
and
actually
contour
has
been
in
that
mode
since
last
Tuesday.
So
we
had
the
discussion
today
about
it
in
the
TOC
meeting.
They
need
to
get
on
it.