►
From YouTube: Kubernetes SIG Apps 20210809
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
And
we're
recording
so
welcome
to
the
monday
august
9th
session
of
kubernetes
apps.
There
wasn't
a
lot
on
the
agenda
today,
but
I
just
wanted
to
hold
it
anyway.
In
case
anybody
had
anything
that
was
critical
for
discussion.
The
only
discussion
topic
we
have
is
the
controller
revision
endpoints.
C
Yes,
that
is
from
my
side.
I
can
go
ahead
with
that
if,
unless
you
want
to
first
touch
on
other
things,.
B
I
guess
magic.
Okay,
we
can
discuss
this.
C
All
right,
if
you
open
that
click
on
the
link
for
alternative
revision,
you'll
see,
basically
all
the
apps
endpoints
have
conformance
dates
now
by
the
end
of
122.
So
we're
very
excited
about
that.
I
think
we
moved
it
in
three
releases
from
50,
something
all
the
way
up
to
88
coverage,
which
is
fantastic,
so
only
things
left
is
controller
revision.
Seven
endpoints.
C
We
plan
to
do
those
end
points
in
123..
C
If
there
is
any
thoughts
on
it,
if
you
scroll
down
a
little
you'll
see
the
yes,
that's
the
pie
chart
and
the
white
bit
is
the
only
bit
that's
not
covered
yet.
So
if
you
go,
if
you
mouse
over
the
white
bits
inside
the
the
sunburst
that
that's
the
endpoints
that
still
need
tests,
so
all
the
other
endpoints
or
have
e
e2e
test
and
conformance
test.
So
it's
only
those
seven
that
need
coverage.
C
So
we
we
did
start
one
of
our
taste
writers
that
start
looking
at
the
endpoints
and
if
there's
any
thoughts,
any
ideas
we
would
like
to
make
a
life
cycle
test,
testing,
all
of
them
at
once
in
one
single
run.
But
whoever
knows
about
the
end
points,
we
will
appreciate
your
thoughts
and
what
you
think
about
the
way.
It
should
be
this
because,
ultimately
we're
to
write
the
date,
bring
it
back
to
you
and
you
have
to
say
yeah
whether
it's
going
to
hit
conformance
or
not
so
we'll
appreciate
some
information
from
your
side.
C
B
Think
the
difficult
portion
with
controller
revision
is
that
it's
only
used
for
rollback
detection
in
demon
set
and
staple
set
deployment
uses
replica
sets
for
largely
the
same
purpose.
Right.
A
B
B
B
B
Sorry
about
that,
if
you
wanted
to
do
something
else,
as
in
terms
of
just
create
a
controller
revision
and
walk
through
all
the
end
points,
I
don't
think
that
would
be.
B
I
mean
a
bad
idea
if
we
think
that's
what
conformance
means.
I
don't
know
if
it
proves
that,
like
from
the
other
side,
the
conformance
test
for
stateful
set
and
demon
set
are
going
to
prove
that
you've
implemented
the
api
correctly
in
terms
of
your
your
cluster
already,
and
that's
the
part
that
personally,
I
really
care
about.
So
if
we
wanted
to
do
something
and
call
it
performance
just
to
exercise
the
api
directly,
I'm
not
opposed.
C
To
it,
okay,
okay,
so
just
direct
exercise.
So
we
don't
have
to
do
this
because
there
is
already
some
bits
and
pieces
inside.
I
think
damon
said
that
we
looked
at
where
somebody
touched
on
controller
vision
inside
the
diamond
set
folder
or
the
go
file
for
daemon
set.
So
what
we
could
do
is,
then,
how
would
you
propose
pull
that
out
of
the
file
create
its
own
file,
specifically
for
daemon
hold
on
control,
the
division.
D
Hold
on
can
so
basically
what
would
happen
in
the
past
and
I
what
I've
noticed
is
the
api
testing
that
we've
been
adding
and
I
added
similar
to
cron
job
when
gaining
those.
D
There
is
a
separate
test
that
tests
all
of
the
operations
against
any
particular
api
coming
from
creation
through
update
through
deletion
through
list
listing
listing
collections
deleting
collections
and
similar
such
that
at
some
point
in
time
it
can
be
marked
as
the
entire
suit
as
a
conformance.
D
That's
what
we've
been
doing
and
I've
been
meaning
to,
and
I
just
run
out
of
time
over
the
past
couple
of
weeks.
That's
what
we've
been
doing,
also
for
other
ryan
and
and
hippie
hacker
who's,
helping
him
yeah.
D
C
Yeah,
that's
what
in
in
our,
I
don't
know
it's
a
community
thing,
but
that's
what
we
call
a
life
cycle
test
where
you
run
all
the
tests
as
all
the
operations
in
one
single
test.
So
would
you
propose
that
we
create
a
because
daemon
said
got
its
own
file?
Stateful
set
got
its
own
file.
Would
you
say
we
create
a
controller
revision
file
just
exercising
that
api,
or
would
we
have
a
that
run
inside,
for
instance,
diamond
set.
D
Separately,
entirely
separate
from
daemon
sets
or
any
other,
it
should
be.
Oh
yeah.
It
should
be
only
for
testing
the
api
and
nothing
else.
C
D
I'm
not
sure
if
you
need
separate
further,
because
we
already
have
everything
under
e3
apps
sure.
If
we
have
sub-folders
no,
we
don't
have
any
subfolders
per
oracle
type,
so
it
would
go
all
into
test.
Eq
apps
directory
already.
D
Yes-
and
I
will
only
have
the
test
for
a
single
test
for
the
api
for
controller
revision,
and
I
think
that
will
be
sufficient.
D
C
At
the
end
of
the
day,
we're
doing
this
work
for
sick
apps
and
you
are
our
customers,
so
you
tell
us
the
way
you
want
it.
So
what
we'll
do
is
we'll
start
on
that?
We're
just
busy
hacking
real
hard
at
a
proxy
thing
that
we
try
to
get
in
this
release
as
well
as
soon
as
we're
ready
with
that
we
will
do
control
revision
and
so
that
you
don't
have
to
attend
the
conformance
meeting.
C
I
controller
revisions
seem
to
be
fairly
simple
operations
where
we
worked
previously,
there
was
operations
where
you
have
status
and
from
the
conformance
group
they
had
very
specific
ideas
how
status
needs
to
be
tested.
That's
why
many
of
the
tests
have
several
tests
doing
different
things
and
status
is
one
of
those
things
that
they
want
to
separately
test
it,
but
the
controller
revision
doesn't
have
status.
So
I'm
looking
forward
to
to
get
that
all
in
in
one
test
and
get
your
feedback
on
that.