►
Description
Tanzu Community Edition Community Meeting - April 27, 2022
We meet every Wednesday at 11am PDT. We'd love for you to join us live!
This week we covered updates to the progress of v0.12.0, roadmap updates and overall changes coming up to Tanzu Community Edition, and App Toolkit. See full notes here: https://hackmd.io/CiuO4V0AT6WL_TgA47MXBA?view#April-27-2022-Agenda
A
Hi,
everyone
welcome
to
this
week
a
week's
edition
of
a
ton
through
community
edition
weekly
community
meeting.
Today's
date
is
april,
27th
2022..
If
you're
watching
this
recording
on
our
youtube
playlist,
we
encourage
you
to
come.
Join
us
live
we
meet
every
wednesday
at
11
a.m.
Pacific
time
it's
a
great
opportunity
for
you
to
come
listening
on
what
the
maintainers
and
folks
that
are
working
on
the
project
or
doing
provide
feedback,
maybe
bring
up
any
feature,
requests
that
you
have
or
if
there's
anything
you
need
help
with.
A
Also
that's
held
every
second
thursday
of
the
month
at
9.
00
a.m.
India
standard
time
and
if
you
can't
meet
reach
us
live,
we
have
other
opportunities
for
you
to
come
connect
with
us.
We
are
in
the
kubernetes
slack
workspace
and
the
tanzu
community
edition
channel.
You
can
obviously
find
us
in
github
and
get
github
discussions.
A
A
For
those
that
are
here
today
and
then
you're
using
tonsil
community
edition,
we
would
love
to
get
more
details
about
your
usage
of
the
project
and
we've
created
this
pinned
issue,
which
you
would
just
make
a
comment
here,
adding
all
the
details
we
requested
of
you
right
here
about
your
organization,
your
you
know
any
details
about
how
you're
using
it
just
helps
the
team
understand
more
about
how
others
are
using
it.
Also,
it
helps
the
community
understand
how
others
are
using
it
to
help
us
build
better
products.
A
A
On
to
announcements
so
for
content,
we
we've
got
some
things
nailed
down
here
for
what
to
expect
for
our
booth
presents
at
kubecon
europe
and
valencia.
That's
in
may
so
we're
gonna
have
some
fun
workshop
activities
at
the
vmware
booth,
both
physically
and
virtually.
So,
if
you're
unable
to
attend
in
person,
there's
still
opportunity
for
you
for
you
to
participate
virtually
so
we'll
provide
we'll
continue
to
provide
more
details
as
those
comes
up
as
timing
and
dates
and
stuff
like
that,
but
keep
that
on
your
radar.
A
B
So
we've
been
talking-
I
guess
a
bit
informally
about
a
bunch
of
these
things
that
are
about
to
discuss
so
I'd
like
to
just
provide
a
more
structured
way
of
going
about
it.
So
I
guess
the
background
is
tce
is
an
open
source
project.
Everything
is
open
source,
but
right
now
most
contributors
are
in
the
vmware
or
vmware
employees.
So
there's
a
lot
of
internal
stuff
that
internal
work
that
we
need
to
do
about
how
we
about
how
the
project
goes
forward.
B
So
I
just
like
to
read
out
a
few
points
here.
We've
come
to
a
conclusion
which
should
not
be
news
exactly,
but
I
guess
it's
clear
that
tc
is
meant
to
be
an
easily
accessible
common
first
step
to
tanza's
many
possible
journeys,
projects,
offerings
etc
in
the
open
source
space.
It
should
provide
the
pattern
language
to
access
all
of
that
good
stuff.
So
this
is
kind
of
what
our
north
star
is.
B
Ntc
is
more
of
a
community
or
a
collection
of
things
than
a
deliverable
per
se,
even
though
we,
of
course,
we
do
ship
software
and
then
the
goal
really
is
to
get
all
of
these
open
source
things
that
that
we
have
in
tanzu
and
provide
them
in
a
in
a
good
experience.
So
I
guess
the
point
here
is
that
providing
all
that
stuff
as
a
unified
experience
is,
is
more
our
north
star
than
shipping
one
solution
to
one
thing
to
any
one
thing
or
another.
B
So
talking
a
bit
about
focus
we've
had
because
we
are
trying
to
ship
open
source
versions
of
some
things
that
we
have
that
were
not
open
source
or
are
not
open
source.
We
did
have
some
issues:
decoupling,
the
open
source
stuff
from
the
non-open
source
stuff.
This
has
resulted
in
some
blockages
or
conveniences
at
some
point
or
another
long
story
short.
We
want
to
prioritize
for
now
things
that
the
community
has
provided
feedback
on
positive
feedback
on,
so
that
would
be
the
desktop
experience
with
unmanaged
clusters.
B
That's
something
that
it
seems.
It
was
universally
well
received,
like
I
said
before,
since
we're,
since
we
are
aiming
to
be
the
the
one
entry
point
to
all
of
tons
of
oss,
the
user
experience
and
integration
of
all
of
those
things
is
also
something
that
we're
going
to
try
to
focus
on
a
bit
more,
and
we
also
want
to
bring
tce
to
more
environments.
B
So,
for
example,
we
have
a
managed
cluster
running
on
kind,
we're
now
going
to
bring
it
to
mini
cube
as
well.
So
this
focus
on
providing
an
experience
of
all
of
tons
of
solutions
that
can
run
in
many
different
environments.
Whatever
people
are
using
is
something
we
want
to
focus
on
as
well.
So
what
this
means
in
terms
of
next
steps?
B
What
I
mentioned
before
about
the
coupling
between
the
commercial
stuff
and
what
we
want
to
offer
as
open
source
that
decoupling,
so
that
we
can
move
faster
htc
is
something
we
want
to
work
on.
We
do
want
to
provide.
We
want
to
come
up
with
a
solution
like
a
minimum,
run
time
to
light
people
run
tce
on
any
kubernetes,
and
the
technical
details
were
still
going
over.
So
we,
if
you
have
technical
questions
about
this,
the
answer
to
whatever
your
question
is.
Is
we
don't
know
we're
working
on
it?
B
C
As
a
designated
talker,
of
course,
I'll
come
up
with
a
question
the
question,
so
there
was
something
you
said
about
the
north
star
that
really
struck
with
me,
and
now
I
can't
remember
it
so
I'd
like
to
it
was
something
you
said
right
before
that
like
something
like
our
north
star
is
the
integrate.
Was
it
like?
Are
north
stars,
the
integration
of
all
the
open
source
components?
Is
that
what
you
said
again,
because.
B
Yeah,
okay,
yeah,
so
the
the
the
goal
is
so
we
have
this
upstream
model
and
now,
I'm
speaking
about
vmware,
we
have
this
upstream
model
where
most
of
our
products,
they
start
with
an
open
source
foundation
and
we
think
all
of
these
foundations
should
be
openly
available.
So,
whatever
axe
product,
it
is
it's
built
on
open
source,
so
yeah,
there's
stuff,
we
sell,
etc.
B
B
C
B
A
bit
on
that
because
I
don't
want,
I
don't
want
things
to
be
like
oh
tce-
is
where
you
start
before.
You
start
paying
it
paying
for
some
product,
because
that's
not
the
goal
like
right.
We
are
providing
solutions
that
are
real
and
valuable,
and
you
know
it's
a
productive
thing
to
use,
regardless
of
whether
you
are
going
to
move
on
to
paid
projects
or
not.
So
I
don't
want
to
get
that
idea
across
because
that's
not
the
point,
but
I
guess
in
a
sense
you.
C
C
So
then,
what
is
that
thing
that
I
install
when
I
say,
tonzu,
unmanaged,
cluster,
create
or
transit,
create
unmanaged
cluster
or
whatever
the
command
is.
What
have
I
actually
put,
because
everything
else
has
a
project
name
like
we
have
harbor,
we
have
pinniped,
we
have
carvel,
we
have
all
these
things.
Is
there
a
name
for
that
core
thing
that
I'm
laying
down?
What's
our
linux
kernel?
Name,
because
that's
what
I
kind
of
see
here.
D
I
guess
you
know-
and
I
think
there's
a
lot
to
come
with
that
as
well,
but
right
now,
the
way
I
see
on
managed
cluster
today
is
at
the
end.
I
get
a
cluster
that
has
cap
controller,
that
has
our
package
repository
and
I
can
then
go
and
install
those
packages
onto
that
cluster,
which
gives
us
a
pretty
good
way
for
people
on
a
local
workstation,
with
a
single
node
cluster
to
quickly
spin
up
and
iterate
fast.
A
E
Yeah,
I
think,
to
add
on
to
that
I
think,
there's
I
think
it's
it's
a
you
know.
We
started
with
sort
of
the
shortcut
to
try
and
get
the
projects
out
in
the
open
space.
You
know
by
trying
to
sort
of
take
what
we've
done
internally
and
share
it
externally,
and
I
think
that
what
we
saw
was
we
got
really
good
feedback,
which
is
exactly
what
we
wanted.
E
So
it's
like
it's
more
about
curation
and
and
having
this
sort
of
opinionated
but
composable
way
to
to
start
to
play
with
all
the
tons
of
portfolio
products
like
as
an
app
developer.
You
may
be
interested
in,
you
know,
playing
with
tap,
you
know
in
the
the
the
application
life
cycle,
management
and
and
in
that
world
you
don't
necessarily
care
about
multi-cluster
right.
You
just
want
a
cluster
to
try
and
run
your
your
applications
on,
but
as
a
devsecops
or
some
other
platform
operator
type
persona.
E
You
know-
or
we
can
be,
your
guide
posts
on
that.
So
so
I
think
that
the
runtime
becomes
less
important
right.
It's
more
of
an
any
kubernetes
type
space,
and
so
the
kernel
is
kubernetes
and
what
we're
doing
is
simply
giving
you
access
to
all
the
great
things
that
you
can
do
given
that
runtime.
So
if
you
need
a
multi-cluster
runtime,
then
you
look
at
the
multi-class
brass
cluster
aspects
of
the
software
we
provide
or
your
single
cluster.
Then
you
have
unmanaged
clusters
so
forth.
C
I
know,
but
I'm
gonna
have
to
so
this
there's
this
and
a
follow-up
question.
I'm
gonna
have
to
get
up
on
a
stage
and
I'm
gonna
have
to
go
into
a
workshop.
So
I
get
what
the
whole
idea
is
and
I'm
not.
I
thomas
v
did
a
great
job
explaining
what
tons
of
communication
is
I'm
just
trying
to
get
when
I
get
up
on
the
stage
and
I
say
tons
of
cluster
create
what
have
I
just
done.
C
C
F
So
part
of
the
exercise
of
getting
the
details
together,
which
we're
sorry
that
they
are
not
there
yet
is
going
to
be
defining
what
the
base
tanzhu
system
means.
So
we'll
have
an
answer
to
that
when
we
scope
out
v013
regarding
managed
clusters,
we
have
every
intent
in
the
near
term
to
continue
repackaging
the
manage
cluster
functionality,
but
again,
as
jace
put
it
we're
not
going
to
bind
ourselves
so
closely.
To
that
being
the
only
model
where
we
can
show
the
value
of
tanzu.
On
top
of.
B
Yeah,
so
just
just
a
clarification.
What
all
of
this
discussion
means
is
not
that
we
are
removing
something
we
are
not
saying.
Oh
we're
not
going
to
do
this
or
that
anymore,
it's
more
of
doing
like
well
speaking,
specifically
of
the
management
clusters,
functionality,
we're
not
saying
we're
removing
management
clusters.
What
we're
saying
is
there's
a
lot
more
to
tc
than
management
clusters,
and
we
are
going
to
try
and
not
be
stuck
on
anything.
G
Right
you,
you
may
be
starting
on
top
of
an
existing
cluster
right,
I
mean
yeah,
but
the
end
game
might
be.
You
might
be
installing
an
unmanaged
cluster,
you
might
be
installing
a
managed
cluster
environment
or
you
might
be
enhancing
or
tons
of
icing
and
existing
other
kubernetes
and
all
of
those
will
be
possible
as
the
end
game.
B
Yeah,
so
as
long
as
we
don't
sound
controversial,
but
just
hypothetically,
if
one
day
vmware
decides
oh,
we
don't
want
to
provide
management
cluster.
We
don't
want
to
build
this
stuff
anymore.
We
want
to
focus
on
whatever
the
I
don't
know.
Cryptocoin
is
I
I
don't
know
the
future,
but
and
then
we
are
not
offering
a
vm
coin.
Oh
my
god,
okay
I'll
I'll
propose
that
to
the
vps
anyway.
B
If,
basically,
we
want
to
offer
the
open
source
counterpart
of
everything
that
we
have.
So
if
one
day
we
the
why
their
company
changes
priorities
in
that
term,
then
that
changes
what
we
can
offer,
but
that's
beyond
all
of
our
pay
grades.
I
suppose,
as
long
as
we
are
offering
it,
then
that's
something
that
we
want
to
see
to
bring
it
as
well.
If
that
makes
any
sense.
H
Okay,
I
also
do
have
one
other
question,
which
is
something
that
had
come
up
initially
in
tc,
which
was
there
was
the
idea
of
how
do
we
upgrade
if
this
is
the
entry
point
to
tanzu?
How
does
someone
move
from
this
to
a
commercial
and
by
decoupling
from
that
that
obviously
becomes
more
difficult?
The
question
is:
has
that
idea
kind
of
been
left
as
not
going
to
be
done
or
not
being
done
for
now?
B
The
way
I'm
thinking
about
it
is
not
so
much
that
it's
not
that
we
gosh
honda
phrases,
basically,
that
what
I
mean
is
that
the
the
core
competency
of
the
tc
car
team
is
to
offer
this
collection
of
solutions
the
the
individual
things
that
we
offer.
They
are
responsibility
of
those
individual
teams.
So,
for
example,
if
we
take
tap
tce
is
not
gonna
be
the
arbiter
of.
Do
we
wanna
offer
a
paid
upgrade
for
paid
tap
offerings
if
you
start
from
tc,
that's
not
our
call
to
make
so.
B
B
G
E
H
E
G
G
B
H
Like
dev
staging,
usually
it
starts
in.
You
know:
quick
iterative
development
testing
things
out
moves
to
devon,
staging
a
lot
of
times,
organizations
that
what
we're
seeing
is
that
they're,
starting
with
let's
say
a
commercial
offering
in
production,
but
don't
plan
on
paying
for
anything
in
dev
and
staging
at
the
beginning
and
then
down
the
road.
They
come
and
say:
hey.
We
want
to
pay
for
that
too,
and
you
want
to
give
the
same
experience
in
the
dev
environment.
H
I
D
I
Yeah
so
app
toolkit
version,
0.2.0
came
out
primary
changes
from
also
a
brief
thing
of
app
toolkit.
Essentially,
the
idea
behind
it
is
it
throws,
together
all
of
the
tab,
components
that
are
open
source
and
lets
you
install
them
with
one
package
that
kind
of
manages
them
all.
Rather
than
going
and
configuring
everything
individually.
I
So
what's
new
is
we've
introduced,
the
cartographer
catalog
and
the
kpac
dependencies
packages,
which
were
also
added
in
this
version
of
tce
that
those
two
editions
have
made
it
so
that
if
anyone
had
played
around
with
app
toolkit
0.1.0,
you
originally
had
to
kind
of
do
some
ytting,
which
was
a
little
bit
annoying
because
you
installed
the
app
toolkit
and
then
there
was
some
like
additional
yaml
messing
around
that
you
had
to
do
so.
That's
no
longer
the
case.
I
I
So
the
idea
being,
if
you'd
like
to
just,
have
a
namespace
up
and
ready
to
go
where
you
can
just
start
deploying
your
workloads
to
it.
Then
you
can
provide
a
developer
namespace
by
default.
It
is
default,
but
you
can
now
specify
a
non-default
one
and
it
will
go
set
up
the
kpac
and
supply
chain
and
everything
in
that
name
space
so
that
it's
ready
to
start
deploying
workloads.
I
The
idea
behind
that
is
to
make
it
very
easy
from
the
get-go
to
just
do
a
single,
install
command
and
then
just
have
things
start
working,
but
it
is
still
possible
to
utilize
app
toolkit
and
other
namespaces
in
other
ways.
It
just
requires
a
little
bit
more
knowledge
and
a
little
bit
more
digging
around.
We
kind
of
wanted
to
make
it
easy
to
have
people
at
least
deploy
something
and
see
it
work
yeah.
So
if
anyone
has
any
questions,
feel
free
to.
H
You
have
to
create
role
bindings
the
roles,
the
service
account
the
in
top
there's
even
more,
but
you
have
to
create
a
lot
of
resources
just
to
make
the
basic
supply
chain,
let
alone
anything
that
you
add
tecton
or
any
testing
into
to
work.
Having
that
is
just
like
a
cli
command
would
make
it
really
easy
to
maybe
get
started
with
that
and
use
it
more
efficiently
than
just
a
single
name
space,
although
it
is
great
already
to
have
that
for
the
single
namespace
getting
started.
I
H
C
I
have
a
quick
question
related
to
that,
and
I
don't
know
if
I
just
didn't
see
it
in
the
doc,
but
it
is
so.
I
think
what
scott
just
talked
about
is
I've
already
got
a
pre-existing
namespace.
Is
it
possible?
Is
app
toolkit
installed
cluster
wide,
or
is
it
just
installed
in
that
namespace
like?
Can
I
then
use
app
toolkit
to
say,
hey
make
a
new
namespace
for
me
and
make
it
ready.
Can
I
do
that
after
I've
once
I've
installed,
it.
I
So
you
can't
tell
app
toolkit
to
go,
make
another
namespace,
but
you
can
enable
another
namespace
that
app
toolkit
that
can
then
operate
in
as
scott
was
saying
you
kind
of
have
to
do
the
role
by
endings.
You
have
to
do
the
all
that
kind
of
stuff
which
is
nasty
right
now,
and
we
do
all
of
that
for
the
developer
name,
space
from
the
get-go.
I
How
you
enable
the
next
namespace
is
a
slog
right
now,
and
so
we
need
to
figure
out
how
we're
going
to
resolve
that
in
the
future
going
forward.
Another
problem
that
we
are
kind
of
starting
to
broach
around
other
namespaces
is,
if
you
try
and
do
if
you
try
and
give
app
toolkit
the
ability
to
create
these
namespaces,
then
it
can.
Theoretically
it
like
will
own
own
them
and
try
and
reconcile
them
to
that
state.
I
And
so,
if
you
have
any
other
tools
that
are
trying
to,
you
know,
add
labels
to
these
namespaces
or
do
anything
like
that.
Then
it
can
get
a
bit
hairy.
So
we
do
have
to
be
a
bit
careful
of
that,
but
yeah,
theoretically.
So
to
answer
your
first
question:
apptoolkit's
installed
classified
you
can
use
it
on
other
things
as
well.
You
just
have
to
create
the
resources
and
the
role
bindings
and
stuff
like
that
in
order
to
utilize
them.
C
I
H
For
the
namespace,
by
the
way
creation,
but
in
packages
that
I've
done
that
have
done
the
same
thing.
One
of
the
things
that
I've
done
is,
you
can
add
a
cap
annotation
to
the
namespace,
telling
it
to
basically
not
deal
with
updates
just
to
forget
any
update
and
just
create
it,
and
you
can
even
tell
it
not
to
delete
it.
Just
have
it
do
an
orphan
when
it
deletes
so
that's
an
easy
way,
at
least
in
cap
controller,
to
be
able
to
do
that
within
the
package.
A
A
D
D
D
We
can
just
call
unmanaged
clustered
wizard
josh
had
given
some
great
feedback
about
this,
not
being
its
own
separate
command.
I
think
I
think
that's
really
really
good,
but
this
definitely
shows
at
least
like
what
this
would
feel
like
what
this
would
look
like
so
right,
here,
kind
of
boots
you
into
this,
where
you
know
you
can
tap
between
all
the
options.
I
can
write:
okay,
cool
john's
cool
cluster.
D
I
can
go
up
to
worker
note
count
or
something-
and
you
know
you
just
start
doing
all
this
stuff
this
this
brought
in
a
library.
That's,
I
think
part
of
what
you
know
I
want
feedback
on
is
is
how
much
we
want
to
bring
in
and
stuff.
So,
if
I
do
this,
we
can
just
go
to
submit
and
it
starts
off
right
away.
I
think
also
plugging
this
into
the
config
option
would
be
really
really
cool
which
josh
had
given
that
feedback
as
well.
D
A
Cool
for
those
watching
from
home,
if
you
have
any
feedback
regarding
anything
that,
like
john
just
showed
or
stuff
about
the
road
map
or
app
toolkit,
please
reach
out
to
us
and
any
other
the
channels
that
we
have
available
to
reach
out.
So
we
have
email,
we
have
twitter,
we
have
slack
and
we
have
github
discussions
all
sorts
of
ways
for
you
to
connect
with
us.
We
would
love
to
to
hear
your
thoughts
on
on
any
of
the
stuff.