►
From YouTube: Cartographer community meeting - Oct. 20th 2021
Description
Cartographer community meetings are held every Wednesday at 8:00 AM PDT/11:00 AM EDT
Feel free to add your discussion topics/questions/ideas to the agenda:
https://bit.ly/2Z67z08
A
Okay,
hello
and
welcome
everyone
to
the
first
cartographer
community
meeting
today
is
october,
the
20th
and
well.
We
really
appreciate
that
you
are
watching
the
recording
or
joining
us
live
for
yeah.
Probably
most
of
you
are
aware,
but
photographer
is
an
open
source
project
that
was
released
on
october.
The
5th
basically
two
weeks
ago,
released
to
the
community
and
the
community
meetings
are
one
of
the
communication
paths
we
have
with
you
all
to
discuss
publicly
the
status
of
the
project,
the
important
stuff
and
also
to
gather
your
comments,
questions
and
ideas.
A
A
A
Okay,
so
first
things:
first,
we
agreed
that
community
meetings
will
happen
weekly
on
wednesdays,
8
a.m,
pacific
time,
11
a.m,
eastern
time
or
you
can
convert
to
your
time
zone.
You
can
reach
us
on
this
lak
channel.
This
is
in
the
kubernetes
slack.
Workspace
so
feel
free
to
go
there
and
start
or
continue
the
conversation
there.
The
the
the
main
goal
of
the
agenda
is
to
to
remain
open
right.
So
if
you
have
a
any
questions,
any
topic
you
want
to
discuss.
Please
add
it
to
the
open
mic
section.
A
We
will
talk
a
little
bit
about
the
the
whole
agenda
format.
If
we
need
to
make
some
changes
to
it.
We
have
also
a
google
group.
Well,
you
find
well,
if
you
subscribe
there,
you
will
you
receive
the
the
community.
Many
invites,
so
you
can
add
it
to
your
calendar
and
get
proper
reminders
for
app
and
for
any
new
or
any
news
we
need
to
share
with
the
community.
You
will
find
it
there
and
also
well.
A
A
Okay,
so
for
the
meeting
we
try
to
collect
the
beginning,
who
is
attending
the
community
meeting?
If
you
want
to
add
to
your
name,
your
or
the
organization,
you
represent,
it's
fine,
you
don't
want
to
do
it.
It's
totally.
Okay,
it's
it's
useful
to
you
know
to
be
able
to
connect
absolutely
meetings
and
continue.
Conversations
of
people
feel
free
to
add
your
name
to
the
app
in
this
list.
A
Agenda
right
so
well,
we'll
start
with
welcome.
Welcome
the
first
community
meeting
and
well
for
for
most
of
the
people
out
there
in
the
community.
We
all
the
cartographer
team
are
new
faces
right,
so
we
would
like
to
start
by
introducing
the
female
ask
each
one
of
you
to
self-introduce
to
your
community.
A
G
J
A
B
We
also
separate
the
kind
of
the
the
division
of
control
in
such
a
way.
That
developers,
for
example,
only
really
need
to
worry
about
a
very
small
subset
of
yaml
trying
to
keep
it
as
minimal
as
possible
in
all
things,
yaml
in
as
many
places
as
we
can
so
developers
are
worried
about
writing
a
workload.yaml
which
really
specifies
the
things
that
a
developer
would
care
about,
so
where
their
application
lives,
any
kind
of
environment,
variables,
etc,
and
on
the
flip
side,
the
kind
of
the
operations
team,
the
devops
team,
a
platform
team.
B
You
know
any
other
kind
of
stakeholders
are
able
to
define
what
that
path
to
production
looks
like
cartographer
takes
the
workload.yaml,
which
was
written
by
the
developer
and
the
supply
chain
specification
and
essentially
combines
them
on
on
cluster
to
to
essentially
choreograph
all
of
the
different,
the
different
components
of
the
supply
chain.
The
other
piece
of
it
is
we're
built
on
a
choreography
model
which
allows
us
to
create
paths
to
production
that
are
really
flexible
and
really
swappable.
B
So,
for
example,
if
you
wanted
to
use
kpac
for
building
images
or
you
wanted
to
use
conoco
or
you
wanted
to
use
something
else
that
builds
images,
you
definitely
could
as
part
of
your
path
to
production
and
each
of
the
different
steps
of
the
path
abroad
are
incredibly
flexible
and
easily
swappable
and
so
yeah
at
a
really
high
level.
That
is
cartographer
in
a
nutshell,
there's
a
lot
of
nuance
and
a
lot
of
little
things
that
we
dive
much
more
deeply
into
in
the
documentation.
B
A
Cool,
thank
you.
Daniel
okay,
regarding
the
agenda
itself
remembers
the
first
time
we're
doing
this,
so
we
have
the
chance
to
change
things.
So
yesterday,
rasheed,
you
know
brought
up
to
me.
Some
interesting
points
on
kind
of
everything
is
becoming
up
and
like
right.
So
all
the
items
here
are
are
basically
in
the
in
the
same
place,
so
how
to
establish
priority.
A
I
was
thinking
if
you
know
how
to
do
it
and
if
we
should
do
it,
because
you
know,
let's
say
that
a
community
user
puts
a
question
at
the
end
here
and
he
doesn't
receive
any
of
both
we'll
still
need
to
listen
to
them
right.
We
still
need
to
give
them
priority.
So
my
short
experience
with
this,
and
also
by
being
part
of
some
upstream
communities,
is
that
somehow
happens
organically.
A
It
needs
to
have
you
know.
The
topics
here
need
to
have
some
some
kind
of
sections.
I
don't
know
structure
that
that
was
my
original
idea
with
reviewing
outstanding
ipm
items.
I
don't
know
if
that
makes
sense,
and
also
having
a
section
for
rfcs
that
also
I
don't
know
if
that
makes
sense.
So
I
would
like
to
know
your
thoughts
briefly
around
this
also.
This
will
happen
organically
throughout
the
weeks,
but
if
you
have
some
thoughts
around
how
to
organize
this.
L
So
I'll
just
jump
in
as
a
not
cartographer
contributor.
Not
yet
I
for
me,
what
would
be
helpful
is
a
like
a
high
level
overview
of
what's
going
on,
if
I
can
make
it
to
a
community
community
meeting
once
a
month
or
every
couple
of
weeks
having
an
idea
of
like.
What's
what's
the
overall
set
of
projects
or
works
that
are
going
on,
I
try
to
attend
the
six
store
meetings
regularly
and
they
kind
of
start
with
a
round
table
of
the
main
projects
right.
L
So
there's
a
cosign
project
and
a
full
co,
and
they
they
do
a
brief
update
for
each
of
those
and
then
inside
of
those
sections.
They
have
links
to
the
deep
dive
topics
for
specific
rfc
proposal
for
this
area
and-
and
I
don't
know
how
cartographers
structured,
what
what
makes
sense
the
right
way
there.
But
for
me,
like
a
high
level
overview
of
the
work
and
the
direction
the
project
is
going
would
be,
would
be
helpful.
D
D
A
F
F
You
know
similar
to
the
template
author,
there's
no
way
for
the
supply
chain,
author
to
say:
well,
if
that's
not
supplied,
here's,
what
the
default
value
should
be,
and
so
we've
already
had
users
who
have
asked
us
and
said
this
is
a
something
that
we
would
need
to
work
around.
We
would
really
appreciate
being
able
to
do
that
parameter
passing
similarly
or
not.
F
If
if
a
template
is
expecting
variable
foo,
then
the
supply
chain
just
says:
pram,
foo
and
because
template
authors
you,
you
can
have
two
template
authors
that
both
ask
for
foo.
We
need
some
way
to
disambiguate
for
the
developer
when
the
developer
specifies
foo
that
the
supply
chain
author
may
be
passing
foo
to
resource
a
or
resource
b.
So
we'll
need
the
temp
the
developer,
to
specify
a
component
or
sorry
resource,
one
foo
and
then
resource
two
foo.
H
H
You
know
based
on
different
services
and
then
those
services
can
offer
you
know
together
can
kind
of
cooperate
to
offer
configuration
in
the
workload
and
so
kind
of
my
proposal
at
the
bottom
of
that
is,
you
know,
could
we
kind
of
make
that
params
map
and
workload
sort
of
a
special
easy
to
access?
You
know
map.
H
Let
operators
override
that
with
kind
of
constant
parameters
that
don't
templatize
against
the
workload
so
that
we
can't
so
we
don't
introduce
more
coupling
kind
of
between
those
components,
so
they
can
still
override
them,
which
I
think
was
a
goal
like.
If
you're
an
operator,
you
could
still
override
a
particular
value
over
a
template
and
then
kind
of
allow
defaults
in
the
template
as
well,
so
that
you
know,
if
you
can
have
a
template
that
has
defaults.
You
don't
have
to
use
ytt
or
you
know,
come
up
with
a
new
and
json
path.
H
Notation
for
defaults,
there's
still
an
opportunity
for
an
operator
to
provide
something
that
looks
like
a
default
in
the
supply
chain,
but
then
the
developer
could
still
override
it
through
the
workload
I'm
wondering
if
that
kind
of
hits
enough
of
those.
The
kind
of
problems
we're
facing
right
now
with
parameterization.
D
Sort
of
requires
some
orcish
orchestrations,
probably
not
the
right-
coordination
between
template
authors,
some
set
of
idioms
that
get
developed.
Maybe
we
can
provide
guidance
then,
but
I
feel
like
that
would
be
required
yeah.
I
I
can't
jump
on
an
obvious
example
right
now,
but
I
know
there
are
certain
variables
that
you
would
provide
like.
I
I
think
classically
would
be
maybe.
D
Credentials
right
so
credentials,
here's
my
service
account
and
I'm
sure
that,
from
their
perspective,
a
template
also
would
be
like.
Oh,
I
just
need
a
service
account,
so
I'll
look
for
the
parameter
service
account
and
then
that
just
becomes
the
one
service
account
and
maybe
there
needs
to
be
multiple
service
accounts
to
satisfy
these
needs,
and
I'm
guessing
that
you
know
two
things
could
come
of
that.
D
H
If
template
authors
understand
that
you
know
the
kind
of
parameters
they
receive,
are
you
know
going
to
be
top
level
workload
items
that
they're
not
going
to
be
names
based
under
the
resources
and
they
can
use
generic
names
when
they
want
to
accept
parameters
that
are
shared
more
specific
names.
They
want
to
accept
parameters
that
are
pretty
specific
to
their
their
templates.
So
the
the
name
spacing
issue.
H
You
know,
I
think,
creating
a
simple
interface
where
you
don't
you
don't
couple
to
you
know
k-pac,
specifically
when
you're
adding
parameters
right
that
the
kind
of
template
authors
can
you
know
have
conventions
to.
You
know
kind
of
work
through
to
me
that
that
hits
the
trade-off
a
little
you
know
or
like
the
trade-off.
There
seems
a
little
bit
better
than
forcing
the
workload
the
person
who
writes
the
workload
to
think
to
know.
H
D
F
And
I
I
think
that
one
of
the
one
of
my
concerns
is
who
do
we
expect
to
know
about
which
actors
and
when
and
I
don't
expect
template
authors
to
be
aware
of
other
template
authors,
and
I
expect
them
to
be
the
earliest
actors
in
in
the
supply
chain
that
they
write.
They
write
months
before
the
template
is
actually
used
and
then
the
conversely,
I
think
of
the
developer
as
the
last
actor
and
the
one
that
has
the
most
communication
from
the
supply.
Like
the
supply
chain
author.
F
It
knows
all
the
templates
that
it's
referring
to
and
they
can
specify
to
the
developer.
Here
are
all
the
fields
that
you
need
to
to
fill
in
like
x,
y
and
z.
But
when
we
say
I
think,
there's
an
implicit
and
implicit
unders,
an
implicit
assumption
in
what
you
were
saying
that
every
template
author
would
would
settle
on
the
same
understanding
of
which
variables
would
be
shared
and
which
ones
would
it
be.
H
As
an
operator
right,
I
think
it
should
be
really
easy
to
make
changes
to
your
supply
chain
without
having
to
tell
all
of
your
developers
that
they
have
to
modify
all
of
their
workloads
or
whereas
a
developer
who's
created
an
application.
You
know
the
application
that
the
workload
gamble
you
create.
H
It
seems
important
to
be
able
to
take
that
to
different
places
right
and
then,
and
in
some
instances
there's
you
know
there
might
be
a
scan,
that's
required
and
you
might
have
to
provide
some
configuration
for
the
scanner
in
other
cases
that
scan
resource
might
not
be
there
right.
The
like
for
an
image
scan.
H
I
think
you
know,
I
understand
the
benefit
of
having
a
tight
contract
right
and
if,
if
we,
if
the
goal
was
you
know,
operator
creates
all
of
this
kind
of
static
infrastructure,
then
asks
you
know,
documents
that
then
asks
developers
to
bring
workloads
to
that
infrastructure.
I
think
it
would
work
well
to
have
more
of
that
name
spacing,
but
you
know
to
me:
the
supply
chain
is
kind
of
like
a
drag
and
drop
interface
that
the
operator
can
kind
of
change.
H
H
H
D
Oh
yeah-
and
this
is
one
of
those
things
that
came
up
for
me
in
priorities.
I
we
talked
about
this
last
week
in
our
first
of
these
meetings
that
was
private
before
we
established
this
open
forum.
I
just
want
to
make
sure
that
previous
business
we
get
out
of
the
way
so
we
spoke
about.
We
spoke
about
the
standards
for
like
finding
an
idiomatic
or
standard
way
of
doing
error
returns
and
having
those
errors.
I
think
our
intention
was
to
keep
stack
traces,
but
from
what
I
can
see.
D
The
only
time
we
actually
saw
stack
traces
must
have
been
coming
from
people
who
were
using
the
github
package
because
the
standard
the
standard
go
standard,
library
errors,
don't
log
the
stack
trace,
it
would
seem
so
so
I
came
up
with
two
proposals.
We
we
stick
to
the
standard
lib
where
we
lose
access
to
most
of
the
stack
trace
output
in
our
error
logging,
unless
we're
logging
third
party
errors
that
are
using
that
github
package
anyway
or
we
can
just
use.
In
that
case,
we
just
use
format,
error.
D
F,
we
don't
need
to
use
errors.
New
format,
f
returns.
The
same
kind
of
object,
no
loss
of
information,
because
there
isn't
any
stack
trace
in
there.
The
alternative
is,
we
use
github's,
the
the
the
package
errors
on
github,
so
it's
less
conventional,
although
I
still
see
plenty
of
people
using
it
and
it
has
stack
traces.
It
just
gives
it
to
you,
and
in
that
case
you
use
either
errors
errors,
f,
error,
f
or
errors
new.
D
G
D
H
I
don't
want
to
detract
from
the
question
of
you
know:
should
how
should
we
do
stack
traces,
but
I
think
the
pkg
errors,
one
on
github
is
owned
by
dave
cheney.
It's
not
like
a.
He
just
got
the
pkg
username
on
github,
it's
not
a
github
specific
thing,
and
it's
I
think
it's.
I
don't
think
he
plans
to
maintain
it
anymore.
It
says
it's
in
maintenance
mode,
because
it's
kind
of
been
superseded
by
when
that
functionality
got
integrated
into
the
standard
library.
I
don't
know
if
that
helps.
D
Yeah,
no,
it
does
help,
because
I
did
try
to
look
at
it.
I
mean
I
didn't
didn't
understand
who
was
owning
it,
and
I
know
it
wasn't
a
github
thing.
I
just
should
try
and
differentiate
between
that
and
the
standard
lib.
I
use
the
word
github
because
that's
how
people
write
it
yeah
I
mean
so.
If
he's
planning
on
not
doing
that,
then
it
means
to
me
that
we
should
use
the
standard
lib.
Happily
just
use,
error,
f
and
not
worry
about
errors,
dot
new!
A
E
E
We
separate
them
with
dashes,
but
then
we
also
need
to
name
space
them
by
by
the
test
as
well,
so
they
need
this
like
prefix
before
them.
So
you
can
see
here
like
we
have
something
descriptive.
That
might
be
like
the
name
of
your
test
and
triple
dashes
and
then
something
that
describes
the
test
objects.
E
I
think
we
probably
don't
want
to
use
more
than
255
anyway,
because
at
which
point,
I
think
the
names
of
the
test
objects
are
probably
incomprehensible,
but
63
is
definitely
a
limit
that
you
can
bump
up
against
pretty
easily.
So
what
I'm
arguing
for
is
to
just
universally
change
the
right
hand,
side
of
the
triple
dash
part
to
just
be
like
dot
delimited.
Maybe
something
like
that
just
so
that,
like
you,
don't
keep
easily
bumping
into
that,
because
then
you
end
up
like
really
pruning
names
and
having
to
abbreviate
things.
Sometimes.
E
F
E
Yeah
I'll
plan
a
trial
to
go
through
and
change
all
the
tests,
just
so
that
it's
obvious
that
that's
the
appropriating
and
that
is
a
con
contributing
guide,
right,
yeah,
yeah,
absolutely
so,
logging
design.
This
is
like
something
that's
just
become
apparent.
We
we
picked
up
a
story
recently,
so
we've
had
very
little
requirement
in
the
way
before
about
like
what
we
needed
to
log,
and
so
we've
got
some
very
minimal
stuff.
E
But
this
logging
is
pretty
verbose,
and
so
you
know
I
guess
you
could
say
this
is
the
first
time
we're
really
adding
what
we
might
consider
debug
logging-
and
this
is
kind
of
like
shown
a
bit
of
a
light
on.
You
know
we
just
happen
to
be
using
a
logging
framework
by
convention
and
somewhat
equivalent
to
the
errors
domain.
E
There's
differing
views
on
how
logging
should
be
structured
that
are
out
there,
and
you
know
varying
frameworks
and
approaches
for
that
and,
of
course,
that
kind
of
begs
the
question
like
if
we're
going
to
start
undertaking
doing
debug
logging,
what
what
is?
What
is
our
approach?
How
do
we
want
to
think
about
that?
E
Do
we
want
everything
to
go
into
one
log
bar
debug
logs
terrible?
Do
they
need
to
go
somewhere
else,
and
I
think
quite
potentially,
we
need
to
think
a
lot
more
about
the
stories
that
we've
got
when
we're
reviewing
them.
You
know
what
what
what
is
the
logging
use
case
right?
Who
who
are
the
stakeholders
and
what
will
they
care
about
happening?
E
D
I
think
our
stories
need
to
specify
the
kind
of
log
message
that
a
user
cares
about.
So
I'm
talking
about
info
and
error
all
right,
that's
important
straight
off
the
bat
and
for
us
debugging
as
a
kind
of
user,
including
users
who
are
trying
to
debug
whatever's
going
wrong,
not
necessarily
needs
to
be
in
the
story,
but
needs
to
exist
during
a
review
that
something
with
a
lot
more
context
is
applied
or
is
supplied.
D
I'd
be
curious
to
know
if
there
are
conventions
out
there,
because
it
would
be
preferable
in
my
mind,
to
have
some,
even
if
it's
a
truncated,
debug
log,
a
debug
log
actually
stored
somewhere.
That
can
be
obtained
after
the
fact,
rather
than
asking
a
user
to
reconfigure
their
deployment
to
get
debug
logging
turned
on
so
that
they
can
just
ask
for
a
pod
log,
because
that
would
be
yeah
after
the
fact
tends
to
be
painfully
hard
to
recreate
so
we'd
love.
E
D
H
The
important
thing
is
that
or
like
an
important
way
to
think
about
this
is
the
when
your
controller
logs
it'll
go
into
pod
logs
that
live
on
whatever
node
the
pod
lives
on,
but
then
the
customer
may
set
up,
or
I
mean
sorry
community
working
group-
the
end
user
may
set
up
something
like
fluent
bid
or
fluent
d.
That'll,
collect
kind
of
you
know
pod
logs
across
the
cluster
and
send
them
to
some
log
storage
solution
that
could
keep
them
permanently.
H
You
know,
aside
from
letting
the
component
be
configurable
at
the
log
level
that
it
logs
at
you
know
I
I
don't
tend
to
worry
too
much
like
I
wouldn't
log
every
you
know
millisecond
or
whatever,
but
I
would
tend
to
lean
more
on
verbose
logging.
That
user
can,
you
know,
really
use
to
identify
problems,
as
opposed
to
you
know.
H
G
No,
I
I'd
agree.
I
mean
that's
the
similar
approach
that
I've
been
I'm
familiar
with
yeah
yeah.
In
fact,
I
mean
we
actually
wrapped
a
logging
logarithm
and
enabled
some
nice
environment
variables
to
be
able
to
switch
on
debug
levels
and
different
types
of
formatting
as
well,
because
you
might
want
to
be
able
to
configure
like
stackdriver
formats
so
that,
if
you're
running
on
gcp
users
might
want
to
have
stackdriver
level
logging
and
json
and
davis
different
things
as
well.
D
D
H
D
D
Let's
make
sure
that
we
have
in
our
stories
some
kind
of
id
we
identify
before
the
developers
deep
in
the
weeds
is
what
they're
working
on.
We
identify
the
kinds
of
notices.
We
want
to
hear
all
right,
the
sorts
of
things
a
user
might
expect
at
a
when
an
error
occurs
or
when
there
is
some
information
that
might
be
valuable
to
them
about.
D
What's
what's
going
on
under
the
hood
and
then
debug
logging,
let's
try
and
get
as
much
context
as
we
can
in
there
and
be
verbose
enough
to
to
just
like
not
stress
about
it,
because
we
know
that
it
can
be
a
configurable
level.
We
can
then,
instead
of
stressing
about
how
much
information
to
provide
provide
as
much
as
we
think
is
necessary,
which
is
a
problem
we've
had
in
the
past.
We
have
not
said
enough
information.
E
D
B
I
was
just
gonna
say:
follow
one
on
the
action
item
suggestion
we
should
probably
save
like
the
past
or
the
last
five
minutes
of
this
meeting,
just
to
assign
action
items
to
volunteers,
volunteer
fraction
items
and
then
just
make
sure
that
started
that
way.
We
can
just
ensure
that
issues
get
created
for
them.
A
E
D
D
E
D
D
This
this
was
too
early
on
here.
Sorry,
so
it's
okay,
but
I
just
think
it
was
valuable
to
make
it
shared
that
we're
actually
thinking
about
it.
I
also
think
it's
safe
to
duplicate
the
code
so
long
as
the
test
pass
and
we've
got
a
product
that
works.
I
think
it's
fairly
safe
to
duplicate
the
code
at
the
moment,
because.
D
C
D
E
Was
unfair
like
it
took
up
all
the
space
on
the
other
half
of
this
meeting,
but
this
is
another
interesting
one
because,
like
the
cuddle
tests
are
like,
I
don't
I
don't
know
they
feel
like
what
I
would
normally
call
like
an
acceptance
test,
but
I
mean
the
way
that
we
write
them.
They're,
really
really
obtuse
they're
they're
hard
to
reason
about
like
what
what
we
would
really
expect
features
to
be
used
for
because
they
just
go.
Oh
well.
E
You
know
I
just
want
to
see
the
way
that
something
gets
templated
out
so
I'll,
just
template
a
config
map
or
a
test
object,
and
it's
not
not
always
obvious
to
see
the
the
big
pictures
from
the
cuddle
tests
and
I
wonder
how
much
that's
a
good
or
a
bad
thing.
I
don't
know.
I
know
we
have
the
intent
test.
D
D
D
H
This
may
be
a
little
tangential,
but
you
know
I
know
kubernetes
still
uses
genko
and
gomega,
or
at
least
ginkgo
and
in
some
places,
but
kind
of
they
seem
to
be
moving
away
from
it,
and
it
doesn't
seem
to
be
the
direction
that
a
lot
of
kind
of
open
source
you
know
kate's,
you
know,
controller
projects
are
kind
of
going
these
days.
Do
we
you
know?
G
No,
I
I
think,
like
my
my
general
view
of
tests,
is
just
trying
to
make
them
as
easy
as
possible,
since
people
make
create
lots
of
them
reducing
the
barrier
of
entry
into
just
writing
tests,
along
with
the
code
of
contributions
and
having
it
familiar
to
what
they,
what
other
projects
are.
Having
as
much
consistency
across
projects
does
reduce
that
barrier,
I
think,
do
you
know
what
they're
they're
looking
at
doing?
Just
writing
just
gen
general
go
test
with
cubans,
who's
fakes,
and
things
like
that.
D
G
D
F
D
It
does
that
just
because
we
put
use-case-oriented
language
in
it.
We
have
an
example
right
now,
where
there
is,
there
is
one
test
that
is
use
case-oriented,
another
one
which
is
just
context
oriented.
Given
you
know
in
this
state,
this
is
what's
going
to
happen
versus
bdd
language,
which
is
you
know
the
the
user
scenario.
D
D
You
know-
and
I
was
like
I'd
like
this-
not
because
I
don't
like
ginkgo,
but
because
it
would
give
me
standard
runner
behavior,
which
means
in
the
ide
it
would
be
easier
to
you
know.
Ides
will
integrate
and
tell
me
this
error
failed.
This
error
did
not,
and
it
would
make
more
sense
because
most
ides
know
how
to
handle
anything.
That
is
conventionally
a
go
test.
D
So
I'd
be
interested
in
that
this
is
entirely
orthogonal
to
whether
we
ditch
cuttle
for
something
that's
an
in-memory
test.
So
the
original
thing
just
wanted
to
sort
of
like
draw
a
line
under
that
I
mean
we
definitely
want
to
do
the
work
to
work
out
what
it
would
look
like
to
stop
using
cuddle
and
get
some
in-memory
tests
going,
which
I
think
are
more
friendly
for
the
most
part
when
doing
story
oriented
testing.
D
But
I
would
like
to
see
some
examples
personally
of
people,
because
I've
read
I've
looked
around
to
find
examples
and
struggled
to
find
testing
that
even
makes
any
sense
to
me
personally
in
the
kubernetes
sphere,
so
I'd
love
to
I'd
love
to
get
feedback
from
people
who
have
seen
successful,
open
source
projects
that
are
testing
integration
level
tests
well-
and
I
happily
take
inspiration
from
that,
and
I
think
we
should
all
maybe
review
that
together
rather
than
because
my
situation
is.
I
first
thing
I
thought
of
was
carvel.
G
G
We
would
actually
physically
build
and
deploy
a
cluster
provision
it
and
run
through
some
sort
of
scenarios,
for
example,
create
an
application,
get
it
promote,
so
the
behavior
of
that
making
sure
that
that's
kind
of
that
end-to-end
behavior
isn't
firstly
affected
by
that
change,
that's
kind
of,
but
there's
a
cost
to
that
as
well.
So
you
don't
want
to
be
doing
on
every
single
week
on
every
single
change,
bringing
up
lots
of
clusters
on
different
cloud
providers
as
well.
G
D
Yeah-
and
I
think
that's
a
stylistic
choice
that
not
all
of
us
are
going
to
be
comfortable
with,
because
I
for
one
like
my
regression
tests
to
be
at
the
level
that
run
fast,
but
actually
test
an
integrated
system,
not
a
bunch
of
things.
I
want
to
feel
comfortable
refactoring
all
right,
so
if
we
can
find
examples
of
that
would
be
really
nice.
H
To
me,
the
important
thing
is
like
in
the
long
term,
when
we
have
ideally
many
more
contributors,
you
know
from
different
places
that
it's
it's
really
easy
to
add
tests
that
give
us
all
the
coverage
that
we
need.
You
know
at
the
integration
level
at
unit
level
and
whatever.
So
I
really
like
the
idea
of
looking
at
what
other
projects
they've
been
successful,
have
done
and
what
kind
of
coverage
they
have
and
just
keep
an
open
mind
to
that.
H
D
D
Yeah
we
use,
we
currently
use
api
server,
so
we
run
kubernetes
without
being
able
to
generate
pods.
So
that's
is
it
in
controller
runtime
that
that's?
I
forget
where
it's
test
test
yeah.
I
think
it's
part
of
controller
runtime
right
or
is
it
part
of
anyway?
Wherever
it
is
it
we
we
run
fcd
and
an
api
server.
So
we
can
do
everything
that
doesn't
involve
actually
standing
up
a
pod
and
it.
G
But
it's
still
is:
it's
turned
into
an
episode.
When
you
can
see
you
can
apply
your
resources,
you
can
check
in
your
search.
You
can
actually
interact
with
it
like
it's
an
api
server,
so
it's
just
a
an
interesting
viewpoint.
Really,
okay
I'll
get
to
know
I'll
dive
in
and
gain
understanding.
It's
more
question
really
yeah.
D
But
please,
let's,
let's
see
examples.
If
anyone's
got
great
experience
with
well-tested
open
source
products,
we
can
take
the
lead
from
those
sorts
of
things.
What
we're
doing
is
just
using
our
experience
with
other
entirely
different
products
right
in
entirely
different
scenarios.
We're
not
we're
not
working
as
a
case
controller
developer.
I've
used
this
or
I've
used
this,
and
so
that's
what
we've
rolled
with,
because
it's
what
we
know,
but
if
we
can
see
great
examples
to
follow,
that'll
be
fine.
A
The
session
is
so
interesting
that
we
are
way
past
the
time,
so
hopefully
the
we
will.
We
won't
have
the
chance
to
discuss,
live,
vrs,
rfc
13,
like
family,
so
we'll
have
to
follow
up
the
next
meeting.
If
you
don't
mind
and
also
the
points
that
I
put
here
for
anything
urgent
so
finally
for
the
action
items,
we'll
ask
some
of
you
to
please
voluntarily
take
take
some
of
those
action
items
feel
free
to
add
your
name
to
the
list.