►
Description
Tanzu Community Edition Community Meeting - June 15, 2022
We meet every 1st and 3rd Thursday of the month at 11am PT. We'd love for you to join us live!
We went over what to expect with our roadmap ahead and other updates. Check out the full agenda here: https://hackmd.io/CiuO4V0AT6WL_TgA47MXBA?both#June-15-2022-Agenda
A
Okay,
hello:
everyone
welcome
to
the
tonzu
community
edition
community
meeting.
Today's
date
is
june.
15Th
2022
I'll,
be
your
nancy
today,
nancy's
out
buying
a
new
house
or
moving
into
it,
so
excited
for
her.
If
you're
watching
this
from
home,
we
encourage
you
to
join
us
live.
We
have
two
options
to
choose
from.
A
First
one
is
our
bi-weekly
community
meeting,
which
is
this
one
held
every
first
and
third
wednesday
of
the
month,
and
then
there
is
a
monthly
meeting
that
is
every
second
thursday
of
the
month
at
9.
00
a.m:
india
standard
time
these
meetings
are
your
chance
to
hear
what
the
maintainers
are
working
on.
Ask
questions,
give
feedback
and
meet
other
people
in
the
community.
A
If
you
are
aren't
able
to
attend
live,
you
can
also
find
us
on
the
kubernetes
slack
we're
in
the
tanzu
community
edition
channel,
and
we
hope
you
can
join
us
in
a
future
meeting
those
attending
this
meeting.
We
abide
by
our
code
of
conduct
that
is
published
on
in
our
github
site
in
the
code
of
conduct
document
basically
be
nice,
be
good,
and
if
you
have
anything,
you
would
like
to
discuss
in
this
meeting
feel
free
to
edit
the
hackmd
in
case
you
do
not
have
that.
A
A
So
with
that
I'll
move
on
to
the
announcements
I
kind
of
glossed
over
earlier,
but
the
one
big
thing
that
hopefully
everyone
has
heard
by
now-
is
that
our
meetings
have
moved
to
every
first
and
third
wednesday
of
the
month.
We've
just
found
that
at
least
at
this
point
in
the
project
we
were,
we
just
don't
have
as
much
happening
that
the
weekly
meetings
that
we
had
had
just
didn't
have
enough
content
to
to
really
share
so
at
least
for
the
time
being
twice
a
month.
A
If
things
you
know,
if
things
pick
up
and
there's
other
reasons,
so
we
can
only
change
that
in
the
future
content-wise.
You
know
it's
been
a
few
weeks,
but
I
think
this
is
probably
the
first
one
since
folks
were
at
kubecon.
I
know
a
few
of
you
got
to
meet
each
other
in
person.
I
believe
the
recordings
are
up
from
the
sessions
there.
There
were
a
few
of
our
community
members
that
were
presenting
so
check
those
out.
A
There
is
also
a
new
blog
post.
Cora
has
written
up
the
build
modern
software
supply
chains
with
cartographer
blog
post
some
interesting
reading
there.
So
I
definitely
recommend
checking
that
out.
It's
not
not
a
very
long
read,
it's
got
some
interesting
things,
and
that
is
it
for
announcements.
So,
with
that
I'll
go
on
to
updates
and
hand
things
over
to
v
to
talk
about
our
roadmap
and
product
management.
B
B
B
So
I
just
wanted
everyone
to
know
that.
Currently,
a
lot
of
the
stuff
is
to
be
seen
which
direction
it's
going
to
go
and
yeah.
So
just
just
wanted
everybody
to
know
that
this
is
how
we're
looking
at
things
now
and
hopefully,
there's
some
clarity,
some
more
clarity
about
like
everything
coming
soon,
and
then
we
can
reestablish
the
usual
processes.
A
C
Well,
let
me
start
okay,
thank
you,
hello.
Everyone!
Well,
first
thing
is
last
week
we
have
this
pr.
We
launched
well
before
the
the
break
for
for
kubecon,
so
cubox
is,
and
nowadays
an
add-on
for
for
tce,
so
it
is
included
into
the
the
repo
so
for
those
newbies
in
in
cubase.
Well,
it
is
a
user
interface,
so
you
can
manage
your
applications
in
different
packaging
formats,
supporting
health
packages,
cargo
packages,
helm,
charts
managed
by
flags
and
all
of
them
well
for
a
multi-cluster
configuration
within
the
same
dashboard.
C
So
it
is
really
great,
really
interesting.
We
are
super
excited
to
on
board
into
thanks
to
community
edition,
and
I
think
we
also
add
some
capabilities
to
to
to
transfer
community
edition.
As
you
know,
you
can
add
the
ability
to
manage
current
packages,
as
I
have
mentioned,
but
also
held
packages
that
some
of
our
community
users
are
really
used
to
work
with
home
charts.
E
One
thing
that
we
we
should
probably
make
clear
is
that
this
is
the
first
iteration
of
the
keyboard
extent
or
add-on
or
package,
and
obviously
there
might
be
some
caveats
and
in
the
coming
weeks
we
will
the
cube
upstream,
I
will
be
contributing
with
them.
We
will
be
probably
documenting
all
the
steps
to
get
the
cube
ups
working
because
at
the
end
of
the
day,
qraps
is
an
application
that
runs
on
top
of
your
of
your
kubernetes
cluster,
and
there
is
a
lot
of
different
configuration
options.
E
G
A
So
if
you
haven't
seen
that
yet
this
is
windows
and
mac
integration
in
docker,
desktop
where,
in
the
newer
versions
of
docker,
desktop,
there's
the
capability
to
add
extensions
that
brings
in
capabilities
or
nice
workflows
things
like
that
from
from
others
in
the
community.
So
there
is
a
extension
marketplace
that
has
a
few
things
out
there
and
I
believe,
that's
growing,
but
one
of
the
things
that
that
that
initially
shipped
with
was
our
integration
for
tons
of
community
edition.
A
So
with
this
within
docker
desktop
really
with
a
click
of
a
button,
you
can
have
an
unmanaged
cluster
created.
So
I
think
we've
talked
about
this
in
the
past
meeting.
I
can't
really
remember
now,
because
it's
been
a
little
while,
but
in
case
you
haven't
seen
it.
This
is
what
it
is,
but
the
initial
version
that
we
had
shipped
out
had
some
extra
output
in
the
logging.
A
So
not
really
a
super
exciting
update.
If
you
are
already
aware
of
docker
desktop
extension,
but
just
to
point
out
that
this
output,
now
we
were
able
to
spend
a
little
more
time
on
our
on
how
we
were
doing
things
with
unmanaged
clusters.
With
this
integration,
we
were
able
to
clean
up
some
of
those
references
to
paths
that
were
not
relevant,
so
it's
just
a
little
cleaner
now
and
functionality
wise.
It's
pretty
much.
A
A
H
Yeah
still
kind
of
grinding
away
on
on
development
there
and
doing
some
integra
and
integration
testing
with
a
lot
of
the
the
management
cluster
create
workflows
working
through
a
few
bugs
it's
coming
along
nicely.
But
you
know
that
doesn't
really
probably
mean
much
without
a
visual,
so
maybe
next
next
community
meeting
we
can
give
a
little
demo
on
current
progress.
If
that
would
be
helpful.
E
H
A
H
A
So
if
you
were
interested
wanted
to
check
it
out,
feel
free,
it's
out
there
publicly
on
our
github
repo
and
it's
all
under
the
cli
command,
plugin
ui
directory.
So
the
make
file
that
justin
referred
to
is
there
there's?
I
think
I
think
we
have
at
least
a
little
information
in
the
readme
about
it
so
feel
free
to
check
it
out.
H
I
I
A
A
G
G
That's
intended
to
stay
the
same
like.
Are
we
just
going
to
ask
mini
cube
users
and
and
kind
users
to
like
continue
using
upstream
kubernetes
components,
but
then
run
like
community
edition
like
package
management
and
other
features
on
top,
or
are
we
wanting
people
using
the
tanzu
cli,
at
least
like,
where
possible,
to
be
using
tkg,
kubernetes
components
and
that
sort
of
thing.
G
G
However,
we're
a
hundred
percent
desiring
a
future
state
where
all
the
core
cube
components
and
otherwise
are
coming
from
the
same
binaries
we
use
in
things
like
manage
clusters,
and
so
on.
Once
we
can
build
those
things
at
a
technical
level,
all
we've
got
to
do
as
a
team
is
produce
our
own
kind
image,
which
we've
done
in
the
past
things
like
mini,
cube,
images
and
stuff.
We
haven't
actually
explored
what
involves
the
creation
of
those
since
minicube
has
multiple
providers.
G
It
sounds
like
it
could
be
n
number
of
images
that
need
to
be
produced,
so
perhaps
some
providers,
we
won't
be
able
to
make
this
guarantee,
but
backing
up
100
percently
our
desire
is
to
get
to
a
consistent
image
or
yeah
image.
I
guess
you
could
say
and
we'll
probably
target
that
consistency
on
kind,
since
it's
used
so
widely
and
then
best
effort
all
the
other
providers.
G
Stuff
is
like
what
would
the
maintenance
story
like
be
like,
and
do
we
even
want
other
projects?
You
know
deploying
tce,
or
do
we
only
want
that
kind
of
stuff
to
come
from,
say
like
the
unmanaged
cluster
plug-in
from
the
tons
of
cli?
You
know
I.
I
know
that
there's
like
ongoing
kind
of
like
work
here
as
we
kind
of
expand
this
use
case,
but.
G
Ideally
I
think,
if
I'm
understanding
like
the
situation
you're
in
lee-
and
please
tell
me
if
I'm
wrong
here-
what
we
need
is
a
more
robust
way
to
do
like
the
tonzu
initialization
atop,
a
kubernetes
api
server
cap
controller
package
repositories,
perhaps
like
app
toolkit
all
the
things
that
we
might
want
to
install
the
way
that
folks
can
do
this
today
is
in
a
non-open
source
project
or
product
called
cluster
essentials.
You
can
google
for
that.
G
We
have
started
some
design
dock
work
internally.
I
guess
so
yeah
well
anyways
we
started
internally.
I
would
imagine
it
would
end
up
external
around
how
we
could
make
that
more
robust
and
how
you
could
do
the
equivalent
of
like
a
tonzu
init,
ask
approach
to
bringing
bass,
tonzu
and
all
the
required
components
atop
any
kubernetes.
G
G
And
like
do
we
want
other
people
like
say,
implementing
a
cluster
essentials
type
thing
inside
of
their
product
right
like
if
the
v
cluster
cli
wants
to
deploy
tons
of
community
edition
v
clusters,
yeah
right,
like
what
is
the
right
way
for
that
to
happen
right
like
they
have
that
they
have
that
desire.
They
asked
us
for
that.
I
went
and
looked
into
what
if
it
would
be
technically
possible,
I
found
some
of
some
weird
constraints
and
shortcuts
that
we're
taking,
but
overall
it
is
technically
possible
and
the
implementation
is
not
hard.
G
G
You
know
to
deploy
the
other
cluster
essential
type
things
such
as
controller
and
the
repos
and
like
I,
we
would
easily
be
able
to
like
add
something
like
that
to
I
shouldn't
say
easily,
but
we
would
be
able
to
add
something
like
that.
You
know
to
the
unmanaged
cluster
plug-in
right
like
with
a
flag
or
a
different
sub
command,
or
even
just
an
entire
v
cluster
plug-in.
You
know
in
the
tons
of
cli,
but
that
doesn't
serve
like
the
sort
of
like
you're
not
tapping
into
another
community's
users.
G
You
know
like
you,
you
need
the
tons
of
cli
in
order
to
discover
that,
whereas
with
the
v
cluster
cli
there
is
a
user
base
there
and
they
can
say
you
know
like
oh
okay.
Well,
I
see
this
list
of
four
things
I
can
install.
One
of
them
is
a
tanzu
thing,
maybe
it
says
tanzu,
maybe
it
says
tce.
Maybe
it
says
something
else:
you
know
right,
but
yeah.
G
G
The
first
piece
is
defining
what
our
base
tonzo
system
looks
like
then,
like
you
said
having
some
machine,
readable
descriptor
of
the
componentry
and
then
figuring
out
a
consistent
way
that
community
projects,
perhaps
even
products,
could
slurp
it
up
and
then
our
own
libraries
and
tooling
slurp
it
up
to
essentially
inject
tanzu
atop,
our
own
tkg
or
kubernetes,
so
yeah.
It's.
G
I
think
it's
definitely
in
lieu
of
all
the
news
and
chaos
going
on
it's
definitely
of
interest,
and
if
it's
something
like
you're
in
the
heat
of
right
now,
vni
could
talk
to
you
slack
zoom,
whatever
you
want
to
set
up
and
chat
a
bit
more
about
what
this
would
look
like
and
give
you
some
realistic
ideas
of
if
it's
something
we'd
actually
work
on
or
if
it's
something
we'd
need
folks
who
are
psyched
about
it
that
have
more
bandwidth
to
pick
up.
You
know
so
yeah.