►
From YouTube: Tanzu Community Edition - Kickstart UI Demo
Description
Garry Ing shows us a sneak peek of the kickstart UI that will make it easier for users to onramp into Tanzu Community Edition. Please share any feedback on the proposal: https://github.com/vmware-tanzu/community-edition/issues/3235.
Note: This is still a work in progress and lots more work to do before GA.
B
So
I'm
going
to
step
you
through
a
few
one
particular
follow-up
with
provisioning,
the
management
cluster,
but
I'm
also
going
to
point
out
a
few
things
that
are
of
interest
for,
for
you
all
and
starting
here
where
we
have
a
welcome.
Welcome
page
we're
looking
to
surface
content
that
is
relevant
for
folks
to
understand
what
is
tmz
community
edition,
along
with
documentation
and
things
just
to
get
folks
up
to
speed
as
to
what
we're
going
to
be
going
through
with
creating
clusters
and
working
with
our
workload
clusters
from
here.
B
B
But
the
course
thing
here
is
to
get
started
from
here.
You're
presented
with
two
flows
in
which
you
can
create
a
management
cluster
and
a
workload
cluster,
and
we
also
have
introduced
this
side
panel,
where
you're
able
to
jump
into
those
particular
workflows
and
also
view
the
clusters
that
you've
created
using
tce.
B
So
I'm
going
to
jump
into
create
management
cluster
here
really
familiar
screen,
we're
giving
you
the
affordances
or
listing
of
all
the
providers
that
you're
able
to
deploy
the
management
cluster
to
for
the
workflows
that
we've
been
thinking
about.
We've
been
starting
with
aws,
of
course,
we're
hoping
to
apply
the
same
patterns
across
things
like
vsphere
and
azure.
B
B
So
this
is
a
reimagined
kind
of
layout
and
information
architecture
where
we're
parsing
out
the
major
moments
in
the
installation
step.
Here
we
start
with
providing
credentials,
and
then
we
step
through
to
cluster
settings,
regions
configuration
and
a
summary
page
in
order
to
kind
of
get
a
sense
of
what
exactly
is
happening
as
you're
provisioning.
B
The
management
cluster
pattern,
two
that
kind
of
persists
across
all
of
these
moments
is
this
advanced
settings
which
will
enable
you
to
compare
into
more
advanced
kind
of
fields
and
selections
in
order
to
really
fine-tune
the
deployment.
But
from
here
we're
going
to
be
surfacing
the
initial
step
of
authenticating
with
the
provider
that
you're
looking
to
deploy
to
so
clicking
on
connect
from
this
point,
I'm
providing
cluster
name
but
also
kind
of
taking
stock
of
the
complexity
that
comes
with
node
type
selection.
B
Here
so
for
those
who
are
familiar
with
the
aws
flow,
you
might
have
been
familiar
with
the
node
type,
suction
drop
down
and
all
the
numerous
options
that
you
get
from
that
drop
down,
and
so
we're
looking
to
provide
a
little
bit
of
guidance
here
in
terms
of
what
kinds
of
workload
you're
looking
to
deploy
onto
the
cluster
by
having
this
kind
of
curated
lightly
kind
of
opinionated
set
of
kind.
Of
instance.
B
Types
that
will
be
mapped
to
the
provider
that
you've
selected
for
those
who
are
looking
to
get
more
specific
around
what
instance
types
they're
looking
to
deploy.
They
can
click
on
the
advanced
settings
and
you
get
this
advanced
settings
area.
We're
able
to
do
some
further
refinement
and
maybe
even
be
more
specific
as
to
what
kinds
of
instance
types
you
want
to
provision
the
control
plane
cluster
with,
but
for
now
we're
going
to
go
back
to
our
not
advanced
settings
state.
B
Then
from
here
we
have
our
aws
regions,
our
ami
os
image.
You
see
two
key
pairs:
we've
moved
away
from
the
development
versus
production
instance,
type
profiles
that
you
might
have
seen
with
the
broken,
strap
ui.
Instead,
we've
kind
of
started
exploring
this
idea
of
availability
availability
zones
and
be
able
to
toggle
additional
availability
zones
as
needed,
and
also
providing
a
bit
of
guidance
in
terms
of
why
you'd
want
to
do
this,
for
your
control,
plane,
cluster.
B
B
Yeah.
So
that's
kind
of
where
we
are
at
now.
There
is
the
github
proposal
issue,
which
kind
of
articulates
what
you
you,
what
I
just
showed
here,
but
also
we're
collecting
feedback
from
that
issue.
So
more
iterations
for
sure
over
the
next
couple
of
weeks
and
we're
very
much
looking
forward
to
hearing
you
all
kind
of
talk
about
and
get
stoked
for
this
ui
concept
that
we're
hoping
to
deliver.
A
C
D
E
Okay,
so
my
feedback
is
this
is
awesome
and
also
amazing
how
fast
you
guys
turn
this
around
like
justin.
Was
it
like
just
two
weeks
ago
that
you
were
saying
there
was
a
proposal
for
this
and
then
now,
two
weeks
later,
we
have
a
really
nice.
I
mean,
I
know
it's
not
finished,
but
it's
a
lot
further.
Along
than
I
inspected
and
expected
in
two
weeks.
My
only
request
is,
I
would
love
to
see
as
the
next
flow
that
you
tackle
is
unmanaged.
E
I
think
unmanaged
is
really
important,
especially
for
getting
new
users
on
board,
because
it's
the
cheapest
and
quickest
way
we
can
get
people
to
start
playing
around
with
tce
so
seeing
that
and
that
actually
should
also
help
you
with
what
a
workload
cluster
should
somewhat
look
like
too,
because
it's
a
very
similar
flow.
That's
just
my
only
request,
but
I
love
the
work.
Let
me
know
when
I
can
beta
test,
because
I'm
super
excited
to
try
or
alpha
test,
or
you
know,
first
working
thing
test.
E
I
might
if
I
was
a
new
user
who
liked
gooeys
and
I
didn't
like
cli's,
and
so
we
could
say
that
the
other
reason
I
might
like
a
ui
is,
if
I'm
spinning
up
a
lot
of
unmanaged
clusters
internally,
and
this
gave
me
the
ability
to
see
all
the
unmanaged
clusters
I
have
locally.
I
might
if
the
man
when
I'm
done
spinning
it
up
there,
was
something
that
this
ui
allowed
me
to
interrogate
about
the
unmanaged
clusters.
E
That's
I
would
have
to
like
you
know
like
if
it
actually
somehow
neatly
flowed
into
some
here's
the
management
cluster.
We
just
spun
up
unmanaged
cluster.
We
just
spun
up
and
here's
the
link
to
its
portal,
or
something
like
that,
so
that
I
could
start
looking
into
my
cluster
right
away
other
than
that,
no
especially,
if
I
mean,
of
course
not
for
cicd
stuff
and
all
that
other
stuff,
but
as
a
new
user,
I
could
see
at
a
new
user
or
workshop.
This
would
be
a
very
nice
way
to
walk
people
through.
F
C
Sean
as
far
as
I
understand
from
josh
I
manage
clusters
will
eventually
be
able
to
integrate
with
more
providers
other
than
kind
right.
So
when
you're
looking
to
manage
clusters
being
provisioned
on
any
of
this
cloud
infrastructure,
obviously
it
makes
a
lot
of
sense
to
have
similar
ui,
because
then
we
get
into
the
all
the
complexities
of
provisioning
understanding
the
infrastructure
foreign
managed
cluster,
which
probably
will
be
like
a
dummy
user.
E
Oh,
that
does
remind
me
of
another
piece
of
feedback
I
wanted
to
give
to
gary
about
the
the
choosing
your
profile
screen.
I
am
disappointed
in
that
screen,
though
I
I
thought,
when
I
had
originally
seen
that
I
thought
that
was
going
to
be,
you
were
going
to
install
a
set
of
plugins.
That
gives
me
like
a
developer
cluster
or
like
it
had
a
whole
bunch
of
stuff
pre-configured,
but
I
I
that
this
doesn't
help
me
that
much
in
terms
of
compute
type
really
I'd.
E
Rather,
actually
we
had
wait
for
this
kind
of
stuff
until
we
get
the
stuff
kartik's
working
on
our
meta
package
is
done,
and
then
this
is
when
I
choose
a
meta
package
and
then
based
on
the
meta
package,
I
choose,
you
can
make
suggestions
about
what
hardware
you
might
want.
But
in
terms
of
this
I
don't.
This
is
not
that
helpful
right
now.
This
takes
up
a
lot
of
space
compared
to
what
I
think
the
value
it
actually
brings
given
what
it
brings.
E
G
Yeah,
I
just
want
to
say
on
the
packaging
side,
we
definitely
hear
you
all,
there's
larger
product
conversations
going
on
around
exactly
what
domain
should
own
the
package
installs
and
all
that
stuff,
so
totally
heard
agree.
It
needs
to
be
there.
I
would
love
to
hear
more
about
if
this
instance
type
approach
is
problematic
in
the
proposal.
G
One
of
the
things
that
we
have
observed
with
end
users
is
that
when
you
drop
down
in
the
existing
kickstart
ui,
the
amount
of
ac2
instance
types
there's
about
77
000
of
them,
and
it's
really
confusing
to
understand
and
reason
about.
What's
going
to
be
adequate
for
your
use
case,
so
going
from
77
options
into
our
reference
to
docs
to
five
known
working
options
that
go
slightly
towards
what
you're,
preferring
via
computer
memory,
seemed
compelling
to
us.
C
If
I
have
time
jose
to
answer
one
of
your
questions
related
to
this
instance
type,
one
thing
that
I
just
noticed
is
that
you're
selecting
instance
type
for
management
cluster,
and
you
are
like
talking
about
the
usage
that
you
are
going
to
give
giving
to
an
to
a
management
cluster
which
I'm
not
an
alps
guy.
But
I
pretty
much
understand
that
management
clusters.
They
are
just
there
to
be
able
to
create
clusters.
C
So,
like
storage,
optimized
memory,
optimization
optimized,
I
don't
know
whether
that
much
makes
a
lot
of
sense
for
for
management
cluster.
It
does
for
workload,
obviously,
but
then
for
for
workload
you
specify
some
type
of
of
like
what
you
are
going
to
be
doing
business
type.
But
then
you
get
to
the
regions
and
that
that
reasons
to
me
it
seems
like
really
complicated
the
fact
that
you
need
to
understand
whether
you
want
to
use
one
a
set
or
three
a
sets.
I
mean.
C
I
know
that
already,
because
I've
been
working
with
this
a
long
time,
but
as
a
user,
I
would
really
not
understand
that
it
means
that
I'm
going
to
deploy
one
node
or
three
nodes.
The
fact
that
I'm
selecting
three
eight
cents
right,
so
that
is
probably
something
that
needs
to
be
better
described
the
fact
that
the
a
set
means
the
number
of
nodes
that
you
are
going
to
be
defining,
because
what,
if
I
want
six
nodes,
how
many
a
sets
do
I
need
to
use
six?
G
Yeah,
I
think
that's
really
good
feedback.
If
you
can
put
that
in
the
proposal
to
jorge,
we
definitely
need
to
rethink
tab,
two
with
regards
to
the
context
of
a
management
cluster
because
you're
absolutely
right.
These
are
more
focused
on
decisions
you'd
make
based
on
workloads
you're
to
run
yeah.
So
I
yeah
get
this
feedback
in
the
proposal.
We
super
appreciate
it.
G
The
line,
we're
balancing
here,
as
as
we
all
try
to
reason
about
this
is
like
how
do
we
give
a
simplified
known,
good
path,
because
so
many
people
are
just
trying
to
get
started
and
failing,
but
still
give
enough
knobs
right.
So
you
know
especially
like
jorge's
feedback
and
your
feedback
steve.
Let's
capture
that
in
the
proposal
and
then
keep
that
kind
of
balancing
act
in
mind
here
and
long
term.
D
If
I
could
also,
you
know,
solicit
feedback
for
one
other
pattern
that
we're
working
around
it
would
be,
for,
I
think,
step
four
right
so
to
josh's
point.
What
we're
trying
to
do
is
include
like
a
reasonable
set
of
defaults,
really
simplified
basic
workflows
for
user
to
you
know,
successfully
deploy
a
management
cluster,
and
then
we
have
these
other
common
configurations
like
cluster
metadata
or
proxy
settings
right,
and
these
are
more
optional
configurations.
D
So
if
anyone
has
any
feedback
or
thoughts
that
they
can
add
to
the
proposal
on
like
you
know
whether
they
feel
that
these,
these
optional
configurations
should
be
part
of
advanced
settings
for
certain
steps
or
if
they
kind
of
deserve
their
own
area
or
like
kind
of
catalog
of
optional
configurations.
That
would
be
helpful
too,
because
I
think
we've
we've
kind
of
gone
back
and
forth
on
this
one,
a
little
bit
internally.