►
From YouTube: Carvel Community Meeting - March 24, 2022
Description
Carvel Community Meeting - March 24, 2022
We meet every Thursday at 10:30am PT. We'd love for you to join us live!
This week we had some great feedback discussion surrounding some of the work the ytt maintainers are doing. Thank you to Leigh Capili for his input! Full agenda notes here: https://hackmd.io/F7g3RT2hR3OcIh-Iznk2hw
A
Hi
everyone
welcome
to
this
week's
edition
of
the
cargill
community
meeting.
Today's
date
is
march:
24th
2022..
If
you're
watching
this
recording
from
home,
we
would
love
for
you
to
come
and
join
us
live.
We
meet
every
thursday
at
10,
30
a.m.
Pacific
time
and
it's
just
a
way
for
you
to
come
and
meet
the
team.
You
can
bring
up
any
discussions.
You
have
about
carnival
any
questions,
any
any
feedback
you
want
to
provide,
or
if
you
just
want
to
sit
and
listen
in
that's
perfectly
fine
as
well.
A
A
If
you
aren't
able
to
join
our
meetings-
and
you
still
want
to
contact
us
and
you
have
you
want
to
provide
something
or
have
a
discussion
or
just
join
the
community
and
meet
other
community
members,
you
can
find
us
in
the
carnival
slack
channel
and
the
kubernetes
slack
workspace
or
on
twitter
at
carnival
underscore
dev
at
any
point.
You
are
interacting
with
us
or
any
member
of
the
community,
whether
it
be
in
the
meeting,
slack
email,
twitter,
etc,
etc.
A
A
If
you're
using
any
of
the
carville
tools,
we
would
love
to
to
know
more
about
how
you're
using
that.
So
we
created
this
pinned
issue
here,
and
it
just
asks
you
to
provide
a
few
details
on
yourself
as
well
as
how
you
are
using
any
of
those
tools
and
you
can
provide
your
organization's
logo.
If
you
have
one
to
that
comment
in
a
png
file
and
we'll
get
it
added
to
the
adopters
page
as
well,
but
that
that
part
is
totally
optional.
A
On
to
announcements,
as
I
mentioned
last
week,
carville
is
hiring
we're
looking
for
a
product
line
manager,
so
click
on
this
job
rec
it.
You
know
if
it
sounds
interesting
to
you,
you
can
come
reach
out
to
us
in
slack
or
send
us
an
email
and
we'd
be
happy
to
answer
any
questions
you
may
have
about
it,
but
we're
we're
a
solid
team,
we're
a
lot
of
fun
and
I'm
personally
biased,
but
I
think
we
we
got
a
pretty
good
bunch
here
and
you
know
if
it
sounds
interesting
to
you.
A
So
content
this
week
we
got
a
pretty
heavily
packed
week
of
content,
so
we
got
three
blog
posts.
Two
of
them
are
surrounding
our
big
release
that
we
had
this
week,
which
was
cap
controllers
0.34,
the
kctrl
so
sumik,
who
is
on
the
cap
team
based
in
india,
wrote
up
two
blog
posts.
One
of
them
is
more
of
an
introduction
to
this
cup.
Controller's
cli
go.
A
Give
that
a
read
give
you
know,
let
us
know
what
you
think
about
it
and
then
the
other
one
talks
about
making
the
most
out
of
clis
and
talking
about
other
approaches
there
as
well,
so
really
interesting,
blog
posts.
Please
go
give
those
a
read
and
let
us
know
what
you
think:
the
next
blog
post,
that
we
we
posted
just
today,
is
by
joelle
joelle.
Anything
you
want
to
touch
on
for
this
post.
B
No,
it
is
just
a
it's
not
like
a
very
big
blog
post,
but
it's
trying
to
answer
some
questions
that
we
heard
people
ask
about
image
package
like.
Why
are
all
bundled
images
copied
to
the
same
repository
or
why
do
I
have
so
many
tags
in
my
repository
and
tries
to
explain
how
a
little
bit,
how
image
package
is
working
and
also
gives
you
some
information
about,
especially
like
some
confusing
terms
that
are
hard
to
find
in
on
the
wild
on
the
internet?
And
people
talk
about
repositories
everywhere
and
things
like
that.
A
Very
cool
and
super
helpful
thanks
joelle
any
questions
on
on
those
posts,
comments.
A
Okay
upcoming,
we
have
a
vlog
coming
from
john
ryan,
the
introduction
to
ytt
overlays
and
then
the
following
week.
We
will
have
garrett
cheadle
doing
something
over
parameterizing.
Your
project
convention
configuration
with
ytt,
so
we're
we're
trying
to
pump
out
a
lot
of
content
every
week
so
that
we
keep
the
community
informed
and
just
talk
about
use
cases
and
whatnot
with
the
tools,
as
well
as
things
that
might
entail
with
our
releases.
A
A
We
would
love
to
have
you
participate
and
for
anyone
who
is
not
a
carnival
maintainer.
We
do
want
to
say
thank
you
by
sending
you
some
swag,
so
we'll
send
you
a
t-shirt
and
yeah.
We
really
appreciate
it,
we'll
publicize
it
through
twitter
and
email
and
slack
and
and
on
here
as
well,
and
if
you're
able
to
attend
the
community
meeting
and
talk
more
about
that
content.
We
would
love
to
have
you
as
well,
but
it's
not
required.
A
C
Well,
there's
a
bunch
of
I
think
it's,
I
guess.
The
people
who
are
here
didn't
didn't
do
most
of
this
work,
but
this
is
the
big
cake,
control
release
and
you
know
otherwise.
I
think
a
lot
of
the
stuff
that
I
guess,
ben
and
dimitri
did
is
a
lot
of
like
smaller
kind
of
like
clean
up
level,
smoothing
out
filling
in
some
gaps.
Smoothing
some
things
over.
A
Awesome
joe,
I
appreciate
that
and
it
sounds
like
we're
we're
starting
the
the
debate
already
with
how
to
refer
it
to
as
is
it
kctrl
or
is
it
k
control
I
heard
dimitri
call
it
kctrl
and
spelled
it
now,
but
now
it
who
knows
is
it.
D
F
A
F
Looking
good
yeah,
no,
no
real
big
changes
here.
The
plans,
the
plan
till
it's
not
the
plan,
maybe
one
thing
to
just
bring
some
awareness
to
is
we
will
be
doing
you
know
some
more
forward
focused
road
mapping
exercises
in
in
the
next
month.
So
if
there
are
things
that
are
on
your
mind,
things
that
you
would
like
to
have
us
consider
and
discuss
as
a
potential
priority.
Please
do
let
us
know.
G
Carrie
yeah-
I
can
talk
through
that,
so
these
are
in
progress
items
right
now,
we're
working
on
some
guides
and
examples
to
make
the
docs
more
clear
and
help
with
newcomers
to
ytt.
So
that's
a
focus
then
also
working
on
better
supporting
windows
paths
and
data.
I
use
tags
so
that's
been
in
progress.
That's
kind
of
going
through,
like
reviews
like
right
now.
E
Cool
yeah
and
then
there's
some
stuff
that
carrie
and
I
have
been
talking
through
around
an
interesting
use
case.
That's
come
up
around,
can
you
use
ytt
and
what
we're
thinking
of
as
a
cookie
cutter
type
use
case
where
most
of
the
files
just
need
to
pass
through
and
a
few
of
them
need
some
templating,
it's
a
little
bit
different
than
like
how
we
built
this
tool
up
from
the
beginning,
so
we're
kind
of
digging
into
that
to
see
what
could
we
do
to
potentially
support
that?
E
Yeah
yeah
there's
actually
even
a
project
called
cookie
cutter
that
that,
if
you
go,
take
a
look
at
what
they're
up
to
so,
I
think,
for
example,
you've
got
like
a
base.
Dev
project
and
you've
got
a
whole
bunch
of
like
starter
artifacts
that
you
just
need
to
have
a
stamp
of
this
whole
directory
structure.
That's
a
project
structure
and
some
of
the
things
you
want
to
be
customized,
like
you
want
to.
E
D
E
That's
it
that's
it.
I
get
it
yeah,
nice,
nice,
read
and
so
like
today,
ytt
defaults
to
anything
it
doesn't
recognize
as
a
file
to
process
is
what
we
call
data,
it's
not
included
in
the
output,
so
you
need
to
mark.
If
you
want
something,
including
the
output,
you
need
to
mark
it
as
like
text
plain
or
something.
E
D
I
was
talking
with
dimitri
a
little
bit
yesterday
about
like
just
then
like
the
need
for
bash,
and
then
like
usually
is
the
thing
that
you
will
reach
for
right
or,
like
you
put
like
some
yt
commands
in
a
make
file
or
something,
and
it
seems
like
there's
just
like
there's
no
sort
of
like
task
management
like
it's
hard
to
factor
stuff
into
a
ytt
program
and
like
tell
ytt
what
to
do.
D
You
have
to
like
use
the
command
line,
flags,
there's
no
config
for
the
command
line
flags,
and
then
we
came
up
with
the
idea
of
maybe
using
like
ytt
libraries
and,
like
writing,
a
small
ytt
program,
to
tell
it
what
to
do.
But
you
cannot
do
like
file
system
operations
and
stuff.
So
that
would
not
work
in
this
case.
D
E
D
I
meant
like
using
ytt
like
using,
live,
not
using
y2c
as
a
library
but
writing
a
ytt
program
that
calls
libraries
from
within
ytt
like
to
so
that
you
can
actually
put
a
file
path
in
your
ytt
program
and
tell
like
ytt
how
to
pull
some
directory
structure
together.
D
G
D
Yeah
but
then,
like
you,
don't
have
control
of
like
what
files
you're
really
writing
to
unless
you
are
dealing
with
those
file
marks
like
in
the
program
so
but
but
I
don't
think
you
could
do
what
you're
talking
about
without
also
having
some
some
simple
copy
command
outside
of
ytt
like
there's,
I
can't
think
of
a
way
to
only
do
it
with
the
programming
language.
So
it's
anyway
yeah.
That's
probably
the
digression,
but
I
think
no.
E
No,
that
that's
really
that's
actually
something
that's
kind
of
came
come
up
around.
This
is
what
about
programmatic
interaction
with
file
marks,
so
it's
a
little
tricky
but
yeah.
Maybe
there's
some
way
of
maybe
there's
something
there
where
if
we
can
identify
what
the
general
case
is
that
we
can
include
a
mechanism
to
be
able
to
support
this
kind
of
thing.
D
I
think
this
is
the
clunkiest
part
of
my
experience
with
ytt
so
far,
which
is
why
dimitri
and
I
talked
about
it
so
much
yesterday-
is
that
it's
it's
hard
to
like
once.
You
know
the
programming
model
and
are
like
using
ytt
as
the
swiss
army
knife.
It's
like
you
start
using
it
for
a
lot
of
things,
but
you
don't
have
a
way
to
stay
organized
with
the
number
of
things
that
you're
doing
with
the
tool.
D
So
then
you
just
run
customize
build
and
if
you're
like,
really
careful
with
what
you're
doing
for
the
most
part,
you
can
put
your
data
values
and
stuff.
Like
in
a
particular
directory
and
like
structure,
your
project,
so
you're
only
passing
one
or
two
file
names
to
your
ytt
build,
but
there
are.
E
Yeah,
it's
an
interesting
thought
having
a
like
a
build
plan
that,
like
helps
drive
these
things
that
are
sort
of
like
you
today,
you
get,
you
get
the
behavior,
you
get
it's
like.
Whatever
it's
doing,
and
then
you
have
to
sort
of
work
within
that
and
there's
a
few
things
you
can
tweak,
but
it
usually
involves
like,
like
you're
talking
about
managing
directory
structures
or
renaming
files
and
stuff.
So
let's
talk
more
about
this.
D
For
sure
yeah
yeah,
it's
like
sort
of
a
higher
level
ux
need
like
once
you
you
know,
but
there
there
might
be
some
stuff
in
the
programming
language
that
can
either
be
used
creatively,
or
maybe
it's
not
there
like,
such
as
the
file
marks
thing.
You
know
you
might
need
another
language
feature
or
another
library
or
something
to
and
then
some
examples
to
make
a
nice
experience
right.
D
Yeah
I
have
a
pretty
like
a
starting
to
increase
in
complexity,
ytt
project
that
I
demoed
yesterday
and
we'll
be
demoing
again
today
that
the
directory
structure,
I
think,
dimitri
and
I
kind
of
sussed
out
it
feels
a
little
bit
sub-optimal,
but
I'm
doing
some
creative
things
like
mixing
different
schemas
from
different
folders
and,
like
I
think,
I'm
gonna
try
some
stuff
and
convert
it
to
something,
that's
flatter
and
simpler
and
uses
libraries
and
see
if
I
can
turn
ytt
into
a
make
file
a
little
bit.
D
So
we
can
probably
sync
up.
You
know
like
next
week
and
see
what
the
result
of
that
experiment
looks
like
would
love
to
see
that
that
sounds
super
cool
cool.
I
know
that
we
were
like
in
the
middle
of
an
agenda.
So
do
we
what's
the
next
bullet
point.
E
Yeah
yeah
it's
it's
related
in
in
a
sense
of
what
we
were
talking
about
using
go
as
a
library,
but
that's
not
what
you
would
meant.
So
the
next
bullet
point
was
about
we're
actually
hearing
a
growing
number
of
folks,
starting
to
use
ytt
as
a
go
module
like
not
just
a
command
line
tool,
but
integrating
it
into
their
tools
and
so
we're
starting
to
make
some
efforts
to
make
that
experience
a
little
bit
better
like
right.
E
E
E
So
you
can
imagine,
there's
like
a
whole
bunch
of
auditing
use
cases
around
here,
where
you
can
name
the
source
for
where
a
value
comes
from.
You
can
document
that
output,
especially
if
it's
if
ytt
output,
is
something
that
is
a
part
of
like
a
git,
ops,
workflow
and
you're,
committing
that
to
a
repo
having
something
that
explains
where
values
came
from
can
make
that
kind
of
troubleshooting
that
comes
up
around
that
a
little
bit
easier.
E
We're
just
kind
of
digging
into
that
see
what
that
might
look
like
and
gauging
the
complexity
on
that.
D
E
Yeah
playing
around
been
talking
with
scott
rosenberg
if
you're
familiar
yeah
and
right
and
we've
been
playing
around
with
the
idea
of
wouldn't
it
be
cool.
If
you
can
know
what
source
and
set
of
overlays
might
have
touched,
a
given
document
so
that,
if
you're
trying
to
figure
out,
what
do
I
need
to
tweak
in
order
to
get
the
output
I
want
it
would
kind
of
point
back
to
that.
So
there's
a
lot
of
interesting
use
cases
around
this.
If,
even
if.
D
It
wasn't
like
practical
to
like.
There
are
some
comments
that
might
be
so
simple.
You
know
that
it's
worth
putting
there
like
when
it's
just
literally
one
call
to
data
values
on
a
line
for
a
value
like
commenting
where
it
came
from,
is
a
really
easy
thing
that
the
parser
could
probably
do,
but
then
there's
like
more
complicated
stuff.
D
That
can
happen
like
if
you're,
if
you're
in
a
loop
or
doing
overlays
and
all
of
that
and
at
a
minimum,
like
you,
could
add
a
sub
command
to
ytt
and
like
trace
like
like,
give
it
a
a
line
of
yaml
in
a
particular
file
in
the
output
and
then
ask
ytt
to
like
basically
run
the
command
and
tell
you
what
it
did
to
generate
that
line,
and
that
might
be
like
technically
possible.
E
Yeah
we've
been,
we've
been
sort
of
exploring
like
what
could
we
do
to
provide
like
a
time
machine
experience
in
in
how
your
yaml's
being
a
pro
being
processed
like
as
you
get
more
and
more
of
that
stuff,
having
the
ability
to
kind
of
see
where
things
are
are
changing,
it
could
be
valuable,
and
if
we
leave
breadcrumbs
that
could
make
it
possible
to
have
tooling
that
could
do
that.
It's
interesting.
D
This
sort
of
debugging
experience
with
the
raw
email,
especially
like
as
the
complexity
of
projects
grows,
is
why
I
think
I
see
like
the
default
recommendation
for
people
to
be
like
building
their
yaml
and
including
it
in
their
repository
in
the
case
of
like
kubernetes
configuration
or
other
yaml
driven
systems,
as
opposed
to
like
committing
ytt
programs
to
the
repo
and
expecting
some
pipeline
or
supply
chain.
D
C
D
Yeah
so
like
I,
I
feel
like
the
templating
step,
it's
it's
hard
to
observe
and
like
work
with
cap
controller,
and
I
know
that
the
k
control
cli
is
going
to
be
like
looking
at
some
of
these
problems
from
like
a
like
a
debugging
and
like
workflow
perspective,
but
as
at
some
point
like
you're,
going
to
need,
like
pre-commit
validation
like
if
say
you're,
using
an
app
with
ypt,
templating
and
you're,
expecting
this
stuff
to
get
inflated
at
runtime.
And
then
you
want
that.
D
You
know
at
least
it's
hermetic,
but
like
I'm,
not
yeah,
I,
if
you're
like
in
a
workflow
where
you're
like
debugging
locally,
and
then
you
only
commit
the
ytt
program
and
then
cap
controller
inflates.
It
like
that's
a
pretty
good
experience
still
but
like
if
the
code
review
portion
of
this,
like
seems
like
there's
a
piece
of
it
there
and.
C
It
sounds
like
you
want
the
right
there's
this
piece
of
vaporware,
that,
like
cake
control,
is
supposed
to
maybe
evolve
into,
which
is
like
the
ability
to
run
cap
controller
locally,
like
I
should
be
able
to
almost
download
like
have
a
shell
script,
where,
like
it
fetches
the
image
locally,
it
runs
ytt
locally,
and
then
I
can
then
I
can
debug
and
introspect.
D
Is
a
really
important
piece
of
the
developer
experience
for
a
lot
of
controller
type
software,
which
is
only
configured
through
a
custom
resource
and
where
the
the
important
logic
pieces
of
the
control
loop
are
a
little
bit
inaccessible
because,
like
people
are
storing
their
custom
resource
and
it's
basically
only
good
at
runtime
inside
the
cluster.
Oh.
C
C
Yeah
the
I
like
there's,
there's
things
we
do
like
with
a
package
repository
where
there's
like
you're,
not
we're
not
even
applying
the
package
repository.
You
gave
us
we're
sticking
our
own
set
of
overlays
that
only
exist
in
cap
controller
source
code
onto
that
package
repository.
So
it's
like.
Do
you
want
to
know?
What's
going
to
happen
to
your
package
repository
yaml
when
it
gets
deployed
on
a
cluster
like
anyways?
Sorry
I,
where
what
are
we
in,
like
the
third
bullet
point
of
the
ytt
status,
update.
E
No
we're
doing
great.
This
is
really
interesting
conversation,
so
don't
cut
it
short
artificially,
but
yeah.
I
also
see
that
there's
like
an
opportunity
here
where
there
might
be
some
templating,
that
you
would
want
to
get
done
inside
of
a
ci
cd,
especially
the
ci
part,
and
then
maybe
there's
some
stuff-
that's
more
alive
that
so
this
gives
an
option
to
be
able
to
actually
do
some
of
that
because
in
ytt
comments
or
code.
D
I
definitely
see
the
like
the
use
case
for
last
mile.
Customizations
is
like
sacred
to
platform
engineers,
because
the
platform
engineer
will
often
own
a
large
portion
of
the
kubernetes
configurations
so
that
custom
resource
is
really
important
to
you
know
someone
who's
building
platform
or
doing
app
operations
like
the
devops
person
of
some
team
and
like
at
least
they're,
like
that's
sort
of
a
separate
use
case,
that's
using
the
same
mechanism,
it's
like.
D
Maybe
you
want
to
actually
build
your
app's
configuration
as
a
raw
yct
program
in
the
cluster
sure
you
can
go
and
do
that.
But
it's
also
a
different
consideration.
When
you're
trying
to
stack
on
overlays
and
add
like
an
iamr
or
you
know,
make
sure
that
somebody's
containers
always
sleep
in
the
pre-stock
book
or
something
you
know
like
those
things
they
might
be.
D
Somebody
else's
problem
domain
completely,
and
this
gives
them
a
place
to
tie
into
you
know
whatever
is
producing
the
yama
portion
of
the
template
phase,
but
that's
like
a
slightly
different
need
than
like
building
the
entire
configuration
and
both
of
these
these
things,
or
only
one
of
these
things
can
happen
and
to
consider
like
the
people
and
their
incentives.
There
is
separate.
E
I
love
what
you're
doing
to
tease
us
apart,
that,
like
there's
application
development,
slash
packaging
needs
like
there's,
templating
needs
in
that,
and
then
you're
also
saying
I'm
hearing
you
say
yeah
and
then
in
the
cluster
there's
like
like.
I
wish
I
had
a
mechanism
to
enforce
policies
to
be
able
to
like
do
these
operational
things
that,
frankly,
the
developers
just
don't
care,
but
we
care
because
we're
we're
on
the
hook
for
making
sure
that
the
stuff's
available
in
production.
E
D
Anyway,
I
don't
want
to
take
up
too
much
space
or
time
on
this,
but
like
just
thanks
for
listening
to
my
thoughts
about
am,
am
I
advocating
for
cap
controller
to
not
be
used?
No,
but
like
there's,
definitely
just
considerations
and
like
usability
concerns
and
limits
to
the
existing
parts
of
the
software
we
have
where
it's
like.
You
know.
D
Some
things
might
be
possible
to
be
used,
and
it's
not
that
you
can't
create
a
good
experience,
but
there
might
be
an
even
better
experience
if
you
like,
make
different
trade-offs
like
storing
a
large
amount
of
your
yaml
and
the
repo
for
the
apps
that
you
control.
While
still
you
know
leveraging
package
installs
for
things
that
you
do
not
package.
A
Crowd
controller,
who
put
this
in,
wants
to
speak
more
on
this.
H
I
put
this
one
in
so
issue:
212,
which
was
opened
by
our
very
own
nick
from
tenzu
community
edition
is
asking
for
a
new
feature
to
be
able
to
add
some
additional
metadata
to
the
package
cr
to
be
able
to
describe
the
contents
within
it,
especially
for
something
that
contains
multiple
pieces
of
software
in
it.
That
are
different
versions.
H
So
we
agree
with
it:
there's
a
pull
request
currently
open,
which
I
have
linked
in
the
document
and
we're
mostly
just
looking
for
some
concrete
use
cases.
H
If
anyone
also
has
this
kind
of
problem
feel
free
to
throw
their
use
case
on
that
pull,
request
or
issue,
and
then
we're
just
looking
for
some
feedback
on
the
the
naming
of
the
the
fields
that
we
are
adding
just
to
make
sure
that
they
are
the
most
semantically
close
to
the
things
that
they
are
attempting
to
describe
because
they
are
effectively
packages
within
packages
and
naming
is
hard.
So.
I
So
yeah,
I
think
somebody
pinged
me
last
week
or
the
week
before
to
ask
to
review
this
pr,
and
I
totally
forgot
I
apologize
for
that.
I
actually
I
got
wrapped
up
in
helping
to
finalize
the
the
first.
I
I
guess
as
we're,
calling
it
a
tce
like
a
meta
package
or
app
toolkit,
which
is
like
one
of
vmware's
first
official,
like
package
of
packages
that
that
we're
pushing
out.
So
this
is
actually
quite
timely
because
these
changes
would
allow
you
know
that
package
to
now
list-
hey,
here's
all
the
software,
that's
inside
of
our
package,
so
I
will
I'll
make
sure
I
get
this
on
my
list
of
things
to
review.
Thank
you.
A
All
right
thanks,
neil
thanks
thanks
nick
really
appreciate
that
and
before
we
go
on
we,
I
don't
know
if
you
saw
carrie's
request
in
the
chat
she's
just
wanting
you
to
share
the
ytt
repo
that
you
had
mentioned.
D
Yeah
for
sure
that
should
be
in
my
github
org
that
I've
been
using
for
a
demo
and
then
I
think
it's
called
tc
eflux
pinifed.
D
D
There
is
a
karvel
subdirectory
on
the
main
commit
right.
Now
and
again
I
might
be
reorganizing
some
things,
but
I
will
link
the
rebo
in
this
right
here
cool.
So
it's
under
the
that
discussion
topic
item
in
there
for
the
devops
columbia,
meetup,
there's
something
to
that
repository.
D
And
there
some
of
the
things
about
the
carnival
subdirectory
in
there
are
a
little
confusing,
mainly
that
the
ytt
lib
folder
is
actually
named
with
two
underscores,
so
it
it
doesn't
actually
mean
anything
and
the
overlays
folder.
Not
all
of
the
files
in
there
are
actually
overlays.
D
D
I
think
the
recording
for
the
atlanta
meetup
is
on
youtube
and
there's
like
it's
like
a
multi-hour
recording,
because
it's
a
meetup
and
there
was
like
multiple
presentations
but
see.
If
I
can
like
find
some
bits
for
my
presentation
and
yeah,
it's
gonna
be
a
good
time.
D
It's
mainly
a
pinniped
demo,
but
I
packaged
up
the
pinniped
stuff
using
ytt,
I'm
using
the
tce
cluster
using
package
installs,
but
the
whole
git
ops
portion
of
it
is
initially
directed
by
flux,
mainly
just
I
know
how
to
use
flux,
because
I
helped
to
build
it,
but
but
there's
a
little
bit
of
cap
controller
stuff
in
there
too.
So
our
back,
our
back
stuff,
is
in
there
there's
a
little
bit
of
cayenne
a
little
bit
of
helm,
it's
kind
of
like
three
package
managers
or
three
get-offs
controllers
being
used
at
once.
D
It's
a
little
bit
crazy.
Anyway.
I
figured
it's
a
good
example
of
where
someone
might
end
up
if
they
tried
to
do
this
in
their
own
environment
and
yeah.
A
Cool,
thankfully,
and
for
those
that
are
watching,
we
is
a
devil
developer
advocate
here
at
vmware
and
we're
really
appreciative
of
all
the
stuff
that
lead
does
for
for
all
the
projects
and
and
for
the
tech
community
at
large.
So
super
appreciative
of
all
the
work
you
do
all
right.
D
I'll
be
joining
the
meetings
more
regularly
so
that
we
can
talk
about
engineering
problems
and
cool
usability
stuff.
So
yeah.
A
Sweet
awesome
really
appreciate
your
input
too.
It's
been
great
all
right,
so
that
leaves
us
with
no
more
discussion
topics,
as
does
anybody
have
anything
they
want
to
bring
up
before
we
head
out.
A
Nope,
okay!
Well
thanks
everyone
for
joining
today.
Great
discussion
really
appreciate
all
the
input
that
we
had
here
today.
If
you're
watching
this
from
home,
we
would
love
for
you
to
come,
join
us
and
and
chime
in
with
your
thoughts
and
feedback.
It's
it's
really
helpful
for
us
to
hear
how
folks
are
using
our
tools,
because
because
we
can
build
them,
but
when
we
learn
more
about
how
people
are
using
them
that
that's
where
we'll
shine
even
brighter.