►
From YouTube: Tanka Community Call 2020-07-07
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
So
hello
and
welcome
to
our
second
tanker
community
call
there's.
Should
we
just?
Is
there
anything
you
want
to
say
in
introduction
tom.
B
Well,
basically,
I
think
the
only
agenda
item
we
really
do
have
today
is
the
new
release
we
just
caught
five
minutes
ago
I
had
a
bit
of
trouble
there
with
our
ci
system,
but
we're
able
to
sort
that
out
and
I
I
will
walk
through
the
changes,
actually
significant
ones
we
did.
But
apart
from
that,
it's
really
open
just
open
discussion
about
whatever
topic
today.
A
B
The
thing
that
probably
most
of
the
time
went
into
was
the
enhancing
of
the
resource
handling
like
what
we
do
with
the
resources
we
receive
from
jsonnet
and
the
two
significant
things
here
are
lists.
On
the
one
hand,
where
we
now
unwrap
these,
so
we
can
actually
label
and
analyze
the
objects
inside
there,
so
they
work
with
a
garbage
collection.
B
All
of
these
kinds
of
things
which
it
previously
didn't,
and
the
second
thing
is
we
kind
of
fixed
default
namespaces,
so
in
terms
of
tanker
default,
namespaces
always
did
exist
like
when
you
didn't
define
a
namespace
on
an
object.
It
always
like
set
that
to
the
namespace
your
environment
belongs
to,
but
this
only
happened
during
apply
and
not
during
show
and
export,
and
because
people
would
like
to
use
tanka
for
like
cd
and
this
information
would
be
lost
if
tanka
wouldn't
handle
apply.
B
We
needed
to
find
a
way
to
have
that
in
yemen,
and
now
we
really
just
set
that
field
in
the
object
if
it's
unset
before
whether
that's
the
way
to
go
forward
with.
I
knew
there
were
some
objections
again
against
that,
and
I
think
we
should
definitely
have
a
general
discussion
discussion
about
this,
but
for
the
sake
of
this
release,
I
really
just
wanted
to
like
fix
the
thing
that
was
broken
and
that
we
can
do
a
potentially
breaking
change
in
the
future.
If
we
agree
on
doing
this.
B
All
right,
the
second
thing
is
that
we
change
tk
export
a
bit.
So
the
really
interesting
things
here
are
that
when
you
now
put
slashes
in
the
filename
template,
it
will
create
directories
for
you
and
also
we
relax
the
check
that
you
can't
like
write
in
into
a
folder
that
already
exists
and
combined.
B
So
that
really
opens
up
your
bridge
to
tools
that
are
yaml
based,
which
is
basically
every
kubernetes
tool
and
we
improve
the
envelopes
command
a
bit.
So
now
it
can
just
output
single
names
which
is
really
handy
for
bash.
Basically,
so
you
can
do
easier,
scripting
without
needing
jq
to
get
the
names
out
of
the
environments
and
also
it
now
has
label
selectors.
B
B
B
A
Great,
so
so
the
second
topic
is
a
little
demo
from
jack
of
I
I
I
think
I
don't
know
how
much
time
you
would
say
you
spent
working
on
this,
but
I
suspect
it's
really
not
very
much.
C
Yes,
it's
it
isn't
very
much
and
you
might
see
that
when
the
when
you
see
what
I've
got,
let
me
oh
hang
on.
How
do
I
share
there?
We
go
no.
What
am
I
doing?
How
do
I
share.
C
There
we
go
sorry
right,
my
entire
screen
yeah,
so
my
wife
last
night
was
a
bit
busy
with
work,
so
I
got
a
little
time
to
fiddle
with
a
topic
which
I'm
sure
we're
all
pretty
passionate
about,
which
is
the
use
of
helm,
which
I
think
we
we
all
love,
helm
and
perhaps.
F
C
Everyone
on
this
call
has
probably
got
some
experience
with
it,
since
it's
so
so
pervasive
in
the
kubernetes
ecosystem,
but
we
I
should
speak
for
mostly
grafana,
I
guess
and
myself,
but
we've
we've.
C
I
want
to
work
on
reconciling
those
two
things
and
I've
seen
some
conversations
on
github
issues
in
the
past
that
have
there's
been
talk
of
a
json
templating
engine
for
helm
that
never
quite
happened
and
there's
there's
various
talk
about
lots
of
different
things,
but
I
wanted
to
hack
around
with
doing
something
that
actually
tests.
C
Some
theories
that
malcolm
and
I
were
sort
of
talking
about
yesterday,
which
is
that
really
we
have
a
pattern,
certainly
in
the
grafana
libraries
and
throughout
a
lot
of
the
jsonic
libraries
that
we
use
this
top
level
underscore
config
object
and,
and
that
really
is
very
similar
to
the
values.yaml,
and
if
you
can
see
the
makefile
I've
got
on
the
right.
C
C
There
we
go
that's
out
of
the
way
now
yeah,
so
values.jsonnet,
but
in
here
this
is
probably
a
bit
unnecessary
of
a
wrapper,
but
I
have
just
a
manifest
yaml
dock,
which
would
be
much
nicer
if
I
could
use
the
tanker
one.
But
of
course
the
native
function
isn't
available.
C
So
I've
got
the
config.lib
summit
that
I
import
here.
So
I'll
show
you
that
as
well,
and
if
anyone
can
guess
which
jsonic
library
this
config
comes
from.
This
is
the
underscore
config
for
the
default.
The
default
configuration
for
one
of
the
json
libraries
that
grafana
has
that's
it's
in
fact
the
cortex
one.
If
anybody
guessed
right-
and
so
this
is
this-
is
the
underscore
config
object
that
we
would
have
usually,
and
it
makes
sense
that
we
can
just
map
this
to
a
values.yaml.
C
C
On
it,
creating
this
helm.libsonic
file,
just
as
a
proof
of
theory
that
malcolm
and
I
had
and
so
there's
this
template
function
here-
that
takes
a
value
and
depending
on
the
type
of
that
value.
C
That
looks
like
this,
so
I
import
the
cortex
library
import,
the
config
I
mean
this
could
just
be
the
local
underscore
config
and
then
I
use
the
library
and
I
mix
in
I
removed
the
namespace
because
I
didn't
realize
that
tanker
took
a
format
string.
So
I
could
stop
the
outputted
namespace
object,
but
yeah
remove
the
namespace,
and
then
I
set
the
underscore
config
to
be
the
helm
template
of
this
conflict
and
then,
when
I
do
a
tk
yeah,
what
do
I
do
make
b
right?
C
This
is
actually
performing
a
tk
export
and
it
creates
all
of
those
templates-
oops,
oh
yeah
hell
and
we'll
look
at
every
file
in
the
directory
and
try
and
evaluate
it
and
when
emacs
is
leaving
symlinks
around
it's
getting
in
the
way.
But
you
could
look
through
the
templates
directory.
Let's
do
a
tk
export
actually,
so
I
can
look
through
this
for
fashion.
C
And
every
area
where
the
underscore
config
existed,
there's
now
the
go
templates
for
helm,
and
this
is
actually
I
could
do
like
a
helm.
I
can't
do
a
helm
anything.
I
need
to
save
that
file.
C
C
Yeah
this
is
this
is
a
waste
of
time
right,
so
helm,
lint,
okay,
we
can
lint
it
helm,
template
and
that
all
looks
good
and
it's
got
all
the
values
substituted
in
like
schema.
C
This
is
what
it
ends
up,
looking
like
in
those
values
of,
but
the
the
side
problem
I
have
is.
I
can't
yet
do
anything
meaningful
with
it.
I
can't
do
a
template,
a
helm,
install
generate
name.
C
I
can't
do
a
helm,
install
because
at
least
for
this
library
the
secret
that
gets
created
is
too
big
for
applying
kubernetes,
and
I
believe
that
I'm
not
sure
if
this
is
something
weird
that
I'm
doing
or
if
it's
just
bumped
up
against
the
helm,
helm
limit
and
the
kubernetes
secret,
nice
and
also
the
other
problem
I've
come
across.
Is
that
when
you
have
libraries
like?
C
Oh
sorry,
let
me
stop
sharing
when
you
have
libraries
like
the
prometheus
case,
sonic
library,
there's
already
go
templating
in
there,
and
so
you
you,
then
have
go
templates
in
go
templates
and
when
helm
tries
to
template
out
it
sees
the
prometheus
templates
and
tries
to
use
the
variables
inside
there.
So
there
needs
to
be
some
way
of
evaluating
that,
but
maybe
using
something
proper
like
go
to
rather
than
just
hacking
around
with
the
json,
it
will
give
us
the
sort
of
power
we
need
to
properly
evaluate
those
things
and
yeah.
C
So
that's
that's
the
proof
of
concept,
it
kind
of
works,
but
it
doesn't
and
I'd
love
to
like
open
up
a
document,
design
doc
that
we
can
all
start
like
talking
about
how
things
might
work
and
also
the
history
of
because
the
more
I
read
about
it,
the
more
I've
seen
attempts
to
try
and
perform
this
reconciliation
between
helm
and
jsonnet,
and
it's
never
happened
and
I'm
not
sure
if
that's
just
not
for
want
of
effort
or
or
if
you
know,
there's
some
some
really
difficult
hurdles
that
people
have
come
across
in
the
past.
C
E
C
Yeah
that
that
bit
is
mostly
fun.
I
think
what
malcolm
and
I
sort
of
thought
the
most
powerful
feature
could
be
is
that
if,
if
you
have
the
ability
to
render
helm
charts
from
jsonnet,
you
have
not
only
that
sort
of
very
convenient
interface
that
a
lot
of
the
community
is
is
used
to
in
the
helm
chart,
but
also
you
have
the
the
language
becomes
the
forefront
of
that
sort
of
discussion,
and
then
people
can
be
more
easily
introduced
to
jsonnet
and
say:
okay,
so
this
helm
chart
satisfies
some
of
our
needs.
C
You
know
it's
the
same
library
in
the
same
code
and
you
know,
but
from
a
grafana
perspective,
we
want
to
make
sure
that
we're
maintaining
better
helm,
charts
and
we
take
ownership
of
these
helm
charts
and
for
us
to
maintain
sort
of
two
disparate
configuration.
Languages
is
one's
definitely
going
to
receive
more
love
than
the
other,
and
it's
going
to
be
the
jsonnet
one,
and
so,
if
we
can,
if
we
can
to
reconcile
the
two,
hopefully
both
get
that
that
high
quality
treatment.
E
C
C
A
I
think
there's
two
there's
two
very
very
different
possibilities
that
this
can
and
possible
situations
that
this
could
solve,
and
I
think
the
one
that
that
that
jack's
been
looking
at
a
bit
more.
There
is
the
question
of
how
do
we,
as
grafana
labs
deal
with
the
fact
that
our
that
our
users
expect
helm
charts
when
we
use
jsomit?
A
So
what
this
could
allow
us
to
do?
It
could
be
an
internal
tool
that
we
use.
We
don't
even
necessarily
need
to
tell
the
world
we're
doing
it,
that
gen
renders
a
helm
chart
that
we
give
out
to
the
world
and
that's
what
they
use
when
they
deploy
loki
or
cortex
or
whatever
yeah.
So
it
makes
our
life
easier
in
terms
of
maintaining
helm
and
keeps
our
helms
charts
more
current
with
what
we're
doing
in
json
at
land.
A
That's
one
use
case.
The
other
use
case
that
I'm
quite
curious
about
is
is
the
mixing
world
where
you
we
have
all
of
these
mix-ins
that
we're
creating
that
are
really
cool
and
are
just
simply
as
as
I
as
far
as
I
understand
it
are
inaccessible
to
anyone
who's
using
helm,
which,
for
whether
we
like
it
or
not,
is
a
significant
portion
of
the
kubernetes
world.
A
So
using
this
you
could
have
a
repository
that
contains
some
mixins
and
probably
a
library
like
prometheus
case
on
it
or
an
equivalent,
and
you
run
you
run
the
tanker
or
something
like
it.
That
renders
a
lump
number
of
templates.
Those
templates
don't
need
to
have
template
value
values
in
them
they
can
just
be
plain
yaml,
and
that
is
a
set
of
config
maps
and
a
grafana
instance,
and
a
prometheus
and
so
on,
and
it
deploys
it
straight
into
a
helm
chart
which
you
commit
into
your
version
control
and
then
you
push.
A
E
E
We
have
kubernetes
openshift,
for
example,
so,
like
with
that
approach,
what
I
still
see
not
really
being
solved
would
be
like
if
you
change,
for
example,
the
namespace
in
your
hand,
chart
it
needs
to
propagate
to
all
the
alerts,
for
example
inside
the
mixes
right,
and
that's
something
where
we
can
be
consistent
with
like
the
json
approach,
and
we
can't
really
be
consistent
with
with
the
approach
of
like
helm
and
and
like
I
don't
know
like
like
it
needs
to
be
sourced
from
like
one
configuration
fire
where
we
specify,
for
example,
the
namespace
and
then
first
we
need
to
generate
the
the
mixin
into
a
mfn.
A
I
mean
jack's
demo
would
work
for
that.
I
think
you
know
for
the
for
the
inserting
of
values.
The
approach
that
jack
showed
would
absolutely
work.
Just
you
know
for
a
simple
number
of
underscore
config
values.
What
you
don't
have
is
conditionals,
you
know
if
or
or
looping
or
those
sorts
of
things
you
just
simply
don't
have
those
options.
C
And
in
fact,
you
kind
of
get
the
I
mean
as
long
as
it's
on
the
j-sonic
side,
you
get
the
conditionals
because
the
it's
still
being
rendered,
you
know
still
being
evaluated
as
jsonnet,
but
with
the
config
variables
sort
of
traced
through
so
it's
I
haven't.
I
haven't
tried
too
much
with
any
sort
of
complex
ones,
but
I'd
love
to
to
give
it
a
go
with
some,
some
better
things
and
then
yeah.
So
hopefully.
E
A
Yeah
exactly
you
know
and
and
whether,
whether
it's
a
whether
it's
prometheus
case
on
it
or
some
other
library
or
some
other
tool,
you
know
the
main
thing
is
just
to
get
it
out
there
and,
and
you
know,
increase
exposure
to
that
model.
B
A
C
But
I
suppose
this
that's
that's.
Probably.
The
similar
hope
that
we
have
with
just
helm
itself
is
that
we
hope
that
people
using
helm
finally
get
fed
up
of
an
indent
12
and
then
they
go.
There's
got
to
be
something
better
for
this,
but
it
seems
you
know
that
isn't
the
case
and
and
perhaps
it's
just
that
helm
provides
a
very
traditional
and
unfamiliar
interface
of
like
we
have
repositories
and
you
you
it's
a
package
manager.
C
You
know,
where's
jsonnet
is
just
a
templating
language,
a
much
better
tool
for
the
templating
part
of
things,
but
it's
it
doesn't
have
all
of
the
rest
of
what
what
helm
sells
itself
as.
B
C
No,
no
for
sure
they've
they've
got
some
open
questions
about
handling
crds
and
don't
I
don't
think
I
can't
believe
more
people
don't
have
problems
with
it.
It
seems
very
odd.
I
guess
it
just
seems
very
day
zero.
Like
you
know,
I've
spun
up
a
thing,
so
I'm
happy
and
I'll
never
touch
it
again,
but
yeah.
C
B
D
A
B
Yeah
basically,
the
idea
behind
roadmap
wishlist
was,
I
kind
of
hoped,
to
get
like
more
tanker
users
in
this
call,
but
apparently
we
either
felt
communicating
this
exists
or
nobody's
interested.
So
the
idea
was
like
to
kind
of
call
for
items.
Somebody
thinks
would
be
a
good
fit
for
a
roadmap
or
also
just
totally
crazy
things.
People
would
like
jsonnet
to
do,
but
don't
even
think
it
could,
but
maybe
we
can
make
it
work
so
in
case
anybody
here
has
specific
wishes
of
what
jsonnet
could
do
for
kubernetes
clusters
just
raise
the
hand.
B
D
I
might
have
a
very
specific
to
tanka,
not
yeah.
It
goes
before
the
the
make
sense
or
or
kobe
needs
there.
Is
this
idea
to
and
get
where
you
can
have
a
comment
on
your
part,
saying
git
dash
something
and
then
git
will
incorporate
that
into
its
comments
interface.
So
if
you
do
get
dash
icdiff
or
something,
then
it
becomes
git
space.
G
D
D
D
Yeah
specific
way,
maybe
with
specific
details
that
are,
that
can
be
provided
on
top
of
what,
what
or
what's
already
known
within
tank
and,
like
you,
have
this
application.
D
B
D
A
I
I
think
I
think
there
is
going
to
come
a
time
when
we
will
want
to
talk
to
talk
about
plugins
and
extensions
and
because
you
know,
for
example,
like
you
know,
I've
spoken
earlier
today
about
vault
support.
A
It's
not
something
that
we
necessarily
need
at
grifan
labs,
but
we
might
want
to
be
able
to
allow
someone
else
to
to
build
something
that
allows
us
to
advance
support
and
something
else
support
and
so
on,
without
necessarily
needing
it
needing
to
go
into
the
code
base.
So
I
think
what
what
you're
saying
is
is
definitely
a
thing
we're
going
to
need
to
consider.
I
think
the
question
is
just
whether
now
is
the
time.
B
A
The
other,
the
other
thing
that
was
that
could
be
worth
mentioning,
is
the
very
interesting
thread
on
jsonnet
itself
about
json
bundler
native
support
within
jsonnet
itself.
B
All
right,
so
I
think
this
one
was
where
some
user
proposed
to
add
remote
importing
to
jsonnet,
or
it
could
just
basically
import
files
over
the
network
without
needing
a
local
tool
like
json
and
bundler,
and
I
think
this
is
also
similar
to
how
cube
cfg
does
it.
But
I've
never
gotten
my
hands
on
that
to
be.
G
B
B
They
have
some
pretty
sophisticated
remote
importer,
and
I
know
that
the
maintainer
is
mostly
using
ipfs
whatever
that
is,
I
don't
know
but
hey,
but
the
one
thing,
I'm
kind
of
not
sure,
is
how
well
remote
importing
plays
with
private
repositories,
because
with
jb
it's
not
an
issue,
we
can
just
clone
private
repos
over
ssh,
but
giving
json
credentials
to
access
http
apis
of
github.
I
don't
know,
don't
even
know
if
that's
possible
to
like
pull
down
private
code.
That
could
be
a
problem.
E
I
mean
like,
like
looking
at
cue,
the
other
kind
of
like
templating
system
that
recently
made
some
like
bigger
ways
right,
like
that's
completely
written
and
go,
and
we
have
kind
of
solved
the
issue
of
dependency
management
and
go
with
jsonnet,
probably
most
people
by
now
using
the
re,
rewritten,
jsonit
and
go
one
could
make
the
argument
that
we
could
kind
of
like
experiment
with
just
using
go
modules
to
to
do
dependency
management,
pull
down
things.
You
would
get
the
cash
of
go
modules
as
well.
E
The
question
is
like
we
do
have
jason
bundler,
which
is
like
kind
of
like
a
just
like
a
thin
wrapper
around
git
commands,
essentially,
and
if,
if
we
really
need
to
like
have
something
different,
then
maybe
if,
if
jsonnet
itself
kind
of
as
a
project
wants
to
maybe
commit
to
to
like
just
like
have
kind
of
the
dependency
on
on
the
go
dependency
system,
I
don't
know
I
guess
that
can
be
brought
up
with
the
issue.
B
As
you
speak
of
go
modules,
I
give
me
one.
Second,
I
kind
of
lost
the
call
here
it
is.
I
know
there
has
recently
been
some
people
experimenting
that
also
come
from
the
queue
space
with
like
re-implementing,
go
modules
or
like
pulling
pieces
of
go
modules
to
create
a
general
purpose
package
manager,
and
while
the
tool
of
just
link
does
a
lot
more,
I
kind
of
don't
understand
what
it
does,
but
it
has
over
20
sub
commands.
B
E
I
mean
yeah
like
I,
I
personally
don't
have
that
problem
right
now,
I'm
totally
happy
with
q.
So
I
don't
know
like
whoever
isn't
happy
with
q.
I
guess
they
need
to
speak
up,
and
then
we
can
have
a
discussion
around
that
sorry.
G
E
B
Yes,
I
think
jasmine
bundle
is
at
least
working
fairly
well.
The
only
thing
it
probably
won't
manage
very
well
is
the
theoretical
case
where
you
have
incompatible
library
versions,
like
version
one
and
two.
If
the
same
thing,
you
need
to
reconcile
that,
but,
to
be
honest,
I'm
not
sure
if
that
will
even
ever
happen
in
the
json
space,
because
we
usually
seem
to
pin
to
master
versions
so
yeah.
E
Already,
yes-
and
we've
been
like
doing
this,
for,
like
seven
openshift
releases
for
six
openshift
releases,
soon
across
multiple
upstream
projects
and
prometheus
in
kind
of
kubernetes,
related
monitoring
projects,
and
so
far
we
haven't
encountered
that
problem.
So
if
someone
does,
then
I
hope
they
would
just
open
an
issue
on
json
bundler
and
we
could
try
to
see
we
can
resolve
it.
If
not,
then
yeah,
I
think
it's
worth
considering
a
different
package
manager
but,
as
I
said
like
for
now,
it's
just
working
fine
for
our
purposes.
E
Even
for
bigger
overshift
projects
like
object.
C
D
We,
if
you
have
been
using
jsnet
for
a
while,
then
you
get
used
to
the
structures
very
fast
and
how
it
all
works
together.
I
think
it's
still,
how
do
you
say
a
door?
You
have
to
go
through
so
like?
B
E
Yeah
like
for
for
basically
like
the
upstream
project
from
us,
like
your
prometheus,
isn't
using
absolute
imports.
So
far,
however,
like
a
few,
like
kind
of
like
more
internal
downstream
openshift
projects
that
we
like
deploy,
I
actually
started
like
whenever
I
essentially
start
like
touching
a
file.
I
just
make
sure
to
like
going
forward
to
just
like
use
the
absolute
import
parts
and
like
by
doing
that,
like
slowly
migrate,
everything
to
the
to
those
new
absolute
import
paths
and
then
yeah.
E
I
guess
like
we
just
like,
eventually
need
to
make
sure
to
like
move
the
move,
the
ones
from
like
your
prometheus,
but
there
hasn't
been
any
like
issue
with
the
current
ones.
We
had
like
a
few
occasions
where
we
needed
to
rename
things
recently,
so
it
just
was
like,
like
I
needed,
to
update
the
import
paths
anyway.
So
that
was
like
the
obvious
choice
to
just
go
with
the
absolute
import
parts
yeah
so
like
slowly
progressing,
but
nothing
like
kind
of
like
like
full-on
migration
in
like
two
days
or
something.
E
E
It
doesn't
again
like
feel
as
big
of
a
deal
to
like
force
users
to
like
adapt
this
tomorrow.
I
think
we
should
like
still
like,
advocate
to
like
start
using
the
absolute
import
paths
and
like
by
doing
that,
and
by
advocating
and
evangelizing
around
it.
I
guess
we
need
to
be
a
good
example.
First,
ourselves.
E
All
right
and
with
ourselves
I
mean
grafana
and
redhead.
B
C
No,
it's
definitely
just
like
a
wish.
I
mean,
I
guess
something
I
think
we
talked
about
like
just
golden
files
would
be
a
start,
but
just
some
framework
you
know
json
itself,
you
could
you
could
do
it
in
json,
but
the
this
sort
of
I
o
side
of
things
is
not
very
nice,
so
it
might
be.
C
When
I
say
do
it
in
json,
I
mean
doing
json
it
language
rather
than
doing
the
json
it
evaluated
like
the
actual
project,
so
we
could
yeah.
I
don't
know
it
feels
like
the
kind
of
thing
that
could
be
developed
in
tanker
and
then,
if
json
it
wants
it,
it
would
go
that
way,
but
just
something
that
can
run
a
bunch
of
files.
C
C
E
E
You
don't
really
know
like
if
any
of
the
tools
that
you
have
up
until
that
point
are
like
like
conforming
to
whatever
kubernetes
version
you're
running
anyway.
Right
like
there
might
be
things
that
are
deprecated
at
some
point
and
your
tools
haven't
caught
up
with
that
and
stuff
like
that.
C
That
that's
true,
I
think,
probably
probably
it'd,
be
worth
making
a
distinction
between
the
kind
of
the
work
that
libraries
are
doing
to
produce
kubernetes
resources
and
the
kind
of
libraries
where
you
build
utility
functions,
for
you
know,
yeah,
similar
to
yeah,
and
then
one
one
makes
a
lot
more
sense
than
the
other
I'll.
C
Take
a
look
at
observability,
driven
development
as
well
and
see
it
might
be
nice
as
well
just
to
have
a
like
a
lightweight
just
a
cert
framework,
or
something
that,
because
there's
probably
regressions
that
you
don't
want
to
introduce
into
your
library
and
then
you're,
never
gonna.
Perhaps
you
don't
want
to
test
the
whole.
You
know
json
output,
but
you
might
want
to
ensure
that
certain
bits
of
it
are
still
still
there.
I
think.
A
That's
that,
for
me,
is
the
key,
if
you,
if
you,
if
you
basically
assert
that
your
yaml
doesn't
change
well,
actually
that's
what
you're
you've
got
you've
already
got
that
with
t
with
diffs
anyway,
so
it's
not
really
giving
you
anything
you
didn't
have,
and
also
it
just
makes
making
any
changes
really
painful,
so
actually
asserting
that
this
is
important.
For
this
reason
now,
if
I
put
in
this
output,
I
input
I
expect
to
get
this
particular
bit
within
my
yaml
output.
Then
great,
then
maybe
that
could
be
something.
A
A
Especially,
I
mean,
I
think,
the
use
case,
the
the
the
use
case
we
commonly
have
is,
you
know,
I'm
sure
pretty
much.
Everyone
on
this
call
is
a
you
know
from
competent
to
expert
in
jsonnet,
in
which
case
we
know
how
to
use
tkdif
or
our
own
equivalents
to
track
this
stuff,
and
we
can
see
what
we've
changed.
A
We
know
why
it
changed,
etc,
but
if
we
want
the
ecosystem
to
grow,
we
want
other
people
to
be
able
to
mess
with
our
libraries
and
that's
when
the
tests
really
kick
in
is
when
the
intent
behind
a
particular
piece
of
code
is
not
clear.
Someone
accidentally
breaks
something
of
ours
that
we
carefully
crafted,
but
they
have
no
idea
why
and
suddenly
the
tests
tell
them.
A
B
C
B
B
E
We
could
have
a
better
name,
but
it's
also
kind
of
like
established
throughout
the
prometheus
community.
At
this
point-
and
we
even
have
like
in
the
prometheus
repository
of
prometheus
itself
and
like
node
export,
we
have
folders,
which
I
think
called
mixin
as
well,
where,
like
the
node
exporter
mix
in,
for
example,
this.
B
I
think
it's
totally
fair
to
have
at
least
hear
about
it.
The
monitoring
thing
is
called
mixins
because,
most
of
the
time,
these
are
actually
mixed
with
something
else,
but
what
I
kind
of
wonder
about,
if
we
I
know
we
at
griffin
labs,
don't
do
it,
but
I
don't
know
about
others.
What
is
about
like
libraries,
that
only
return
kubernetes
resources?
B
E
Yeah
they're,
definitely
not
mexicans
like
mexicans,
are
purely
about
like
the
prometheus
or
like
funnels
or
particles
or
whatever
you
have
like
kind
of
like
I
mean
that
prometheus
rule
format
right
or
like
in
many
cases
as
well,
the
dashboards
for
grafana.
E
So
that's
what
I
kind
of
like
kind
of
like
name
and
mix,
and
anything
outside
of
that
I
mean
we
kind
of
like
just
like
the
projects
that
generate
kubernetes
objects
are
called
like
you,
prometheus
cryptanos,
like
we
just
prefix
them
with
cube.
I
don't
know
like
we,
we've
never
caught
them
modules.
So
that's
the
first
time
I'm
hearing
this,
but
I
don't
know.
A
A
A
A
D
The
name
makes
sense
is
just
saying
what
it
is
intended
to
do,
so
it
expresses
intent
and
it
might
do
something
else.
So
a
library
is
not
necessarily
a
mixin,
because
the
library
could
contain
more
objects
and
it's
it's.
It
depends
on
how
you
consume
it
in
inside
your
json.
E
I
think
there's
a
bigger
discussion
to
have,
and
I
certainly
know
from
frederick
that
he
was
kind
of
like
thinking
about
having
a
monitoring,
mixins
kind
of
v2
proposal,
and
I
think
you
already
talked
to
tom
wiki
about
this
and
various
other
people.
So
I
think,
like
I
mean
this,
this
proposal
is
more
than
two
years
old
at
this
point,
so
we
certainly
learned
a
lot
and
like
the
global,
like
conflict
object,
has
has
brightened
us
a
couple
of
times
in
these
two
plus
years
now.
E
E
So
maybe
I
don't
know,
maybe
we
can
bring
frederick
and
tom
wiki
on
this
call
like
on
the
next
call
and
kind
of
start
discussing
a
v2
proposal,
because,
like
so
far,
I
heard
like
discussions
here
and
there
but
like
there
hasn't
been
like
kind
of
a
kick
off
around
that
topic,
and
I
think
it
makes
sense
to
like
tackle
this
in
a
broader
scope
and
like
have
like
try
to
get
a
v2
proposal
out
there
and
then
have
kind
of
like
that.
Discussion
on
that.
Like
overall
theme.
G
B
A
Great
so
so
I
I
have
a
question
for
you
mathias,
you
know
so
so
we
have
these
things
called
mixins
they're
written
in
jsonnet.
We
deploy
them
using
prometheus
case
on
it,
which
is
which
we
execute
within
tanka.
How
do
you
use
them
and
then
how
many
different
contexts?
What
tubing
do
you
use
to
deploy
these
things.
E
So,
in
general,
like
it
all,
boils
down
to
eventually
we
end
up
with
like
yama
files,
and
they
are
just
like
what
like
just
like
yama
files
that
can
be
applied
to
a
kubernetes
api
right.
So
thinking
about
q
prometheus,
for
example,
we
consume
the
node
exporter
mix
and
the
prometheus
mixin,
the
cd
mix-in
and
maybe
a
few
others,
and
what
what
happens
is
essentially
we
we
have
this
like
global
kind
of
prometheus
alerts,
object.
E
So
what
happens
is
once
we
like
generate
the
manifests
folder,
which
is
like
40
files
that
we
that
we
in
the
end
commit
to
to
the
to
the
repo
for
people
to
just
easily
grab
it
once
we
generate
that
we
will
evaluate
these
bigger
objects
and
then
there's
basically
a
simple
reference
in
the
prometheus
rule,
which
is
our
crd
that
the
prometheus
operator
uses
to
deploy
these
rules
to
to
a
prometheus.
E
But
actually
I
don't
think
it's
a
multi-line
string
because
we
have
like
a
structured,
prometheus
crd
prometheus
with
crb.
So
it's
not
even
a
multi-line
string.
It's
like
an
actual
structure,
so
that's
kind
of
like
the
the
flow
we're
going
for
and
then
in
the
end
we
just
have
young
effects
that
everybody
just
you
know.
E
Exactly
we
have
like
yeah
exactly
like
json
j
vendor
to
get
like
the
things
in
the
dependencies
in
and
then
there's
like.
Essentially,
the
only
thing
we're
wrapping
in
in
that
script
is
for
each
top
level
object.
We
write
them
to
a
separate
file.
So
that's
how
we
end
up
with
like
the
40
files,
but
essentially
it's
just
really
plain
old
json.
E
B
Right,
it's
so
basically,
fundamental
difference
between
both
setups
compared
is
that
ours
is
mostly
based
on
plain
json,
where
we
bundle
all
of
these
into
config
maps
and
do
all
of
the
clever
things
during
evaluation
time.
While
yours
also
includes
your
premises
operator,
which
makes
your
deployment
process
probably
a
bit
simpler
when
looking
from
json,
because
you
can
just
use
the
crds
offered
by
the
tool
without
needing
to
do
all
the
clever
fancy
tricks,
we
we
need
to
right.
E
E
We
could
have
a
prometheus
stateful
set,
so
there
wouldn't
be
any
difference,
but
what
the
prometheus
operator
allows
us
to
do
essentially
is
like
everyone
can
just
deploy
q
prometheus,
but
then,
on
top
of
the
during
run
time
inside
the
cluster,
add
more
prometheus
rules,
crds
and
those
would
get
merged
into
the
same
prometheus.
F
E
E
I
mean
like
to
make
to
make
like
to
explain
kind
of
like
from
where
you're
coming
from
think
of
it,
as
you
would
deploy
like
five
different
conflict
maps
and
your
tool
would
kind
of
like
deploy
empty
config
maps,
and
then
somebody
else
from
somewhere
else
could
like
put
the
actual
contents
into
the
config
map.
B
Another
three
hours
of
talking,
but
to
be
honest,
I
I
do
agree
that
we
should
start
putting
plus
signs
before
the
lines
because
they
would
allow
start
yeah.
But
that's
exactly
the
same
argument
go
takes
with
allowing
trailing
commas,
because
then
you
can
delete
or
comment
out
single
lines
without
needing
to
add
another
one.
G
G
B
C
B
A
D
Yeah,
so
maybe
this
meeting
should
be
encompassing
a
bit
more
like
the
tank
and
the
mixing
and
then,
instead
of
calling
it
the
danker
going
into
the.
B
Chase
netflix
meetup
yeah.
I
guess
we
can
stick
with
the
community
call
name
until
it
outruns
that
format
and
like
currently,
there
is
probably
no
tanker
community
in
here.
So
in
case
what
we
discussed
becomes
boring
for
other
people
that
might
join.
In
that
case,
we
could
split
these
up,
but
for
the
time
being,
this
is
probably
very
okay.
B
D
Yeah,
probably
probably
coming
from
community
stuff
inside
grafana,
it's
also
a
marketing
tactic.
A
I
think
you
know,
and
I
think,
there's
two
very
different
purposes
there.
You
know
and
it's
right
to
call
them
out.
You
know
saying:
hey
world
we've
got
tanker,
it's
really
cool,
come
and
use
it,
and
this
is
how
you
use
it
and
come
and
talk
to
us
about.
It
is
a
very
different
call
from
hey.
If
you're
a
hardcore,
jsonnet
user
who's
working
on
influencing
the
json
ecosystem
wants
to
really
discuss,
it
is
mixing
the
right
name.
Does
jb
really
do
what
it
needs
to
do?
A
It's
a
very
different
set
of
discussions
that
require
a
deeper
level
of
engagement
with
with
jsonnet.
So
I
think
you
know
recognizing
that
at
the
moment
you
know
we
are
the
group
of
people
that
are
turning
up,
but
it
could
quite
well
turn
find
ourselves
in
a
few
months
time
that
we
have
a
bunch
of
newcomers
to
tango,
coming
and
asking
us
to
take
tk
diff.
What
does
tk
diff
do
again?
A
You
know,
in
which
case
we'll
probably
want
to
split
into
two
different
groupings.
E
Common
things
from
outside
rafana,
I'm
still
fine
with
like
having
this,
be
the
tanker
call
and,
as
you
said
like
until
that
comes
too
much
of
a
only
like
user
supporting
video
call
meeting,
then
I'm
super
happy
to
just
combine
it
up
until
then,
and
I'm
happy
to
join
this
one.
So,
let's
see
how
it
goes
in
the
future.