►
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Intro: Kubernetes Architecture SIG - Jaice Singer DuMars, Google
This will introduce the core areas of architectural governance for the Kubernetes project. This will include an introduction to the KEP process, the API review process, conformance testing review, and code organization. Attendees will have a better understanding of how to contribute and participate, as well as what concerns are specific to the SIG.
https://sched.co/MPi4
A
A
So
there
are
two
different
types
of
SIG's,
more
or
less
there's
a
horizontal
sake
or
horizontal
goes
this
way,
a
horizontal
sake
that
is
really
cross-cutting
against
different
silos.
So
you
can
think
of
the
release
team
as
one
of
those
horizontal
SIG's
Sagarika
texture
is
one
of
those
and
cig
p.m.
which
is
product
project
and
program
management.
Those
are
all
ones
that
are
concerned
with
different
silos,
and
then
you
have
these
vertical
slices,
like
storage
or
networking
that
are
really
focused
on
a
very
narrow
expertise
domain.
A
So
these
sort
of
cross-cutting
special
interest
groups
are
really
responsible
for
oversight
across
a
lot
of
processes,
things
that
maybe
affect
different
parts
of
the
project
and
really
keeping
an
eye
on
how
things
interrelate.
So
a
lot
of
what
sig
architecture
was
chartered
to
do,
and
maybe
a
little
bit
of
background
on
that
is
that
we
were
formed
spontaneously.
As
far
as
I
know,
this
is
the
only
sig
that
this
happened,
but
at
the
Leadership
Summit
in
May
of
2017.
A
This
seems
like
a
perfect
application
for
a
sig
to
form,
and
so
people
in
the
room
voted-
and
we
said,
are
we
gonna
do
this
and
it
was
unanimous
and
at
that
point
we
selected
two
chairs
Brian
grant
from
Google
and
I
was
working
at
Microsoft
at
the
time.
So
Brian
Graham
myself
have
been
with
the
architecture
sig
literally
since
the
first
moment
and
yeah
we'll
get
into
that
in
a
bit
more.
But
so
just
a
little
bit
about
Who
I
am
I,
have
a
pretty
long
history
with
the
project.
A
I
was
a
release,
lead
for
the
1.8
and
1.10
releases.
I
am
a
member
of
the
Code
of
Conduct
committee,
which
you
may
or
may
not
know
even
exists,
but
it's
out
there
and
I'm
a
chair
for
sega
architecture
and
sig
p.m.
so
two
cross-cutting,
sic,
SIG's
and
what's
interesting,
is
that
I
see
a
lot
of
those
overlaps
across
projects
so
I'm
one
of
those
people
that
has
sort
of
a
multi
multi
faceted
view
of
different
concerns
across
the
project.
A
So
I
see
things
maybe
from
a
different
angle:
I'm
mature
emeritus,
meaning
that
I'm
no
longer
doing
the
the
job,
but
I
was
released.
Zig
and
zag.
A
share
chair
and
I
currently
work
at
Google
on
cloud
native
strategy
and
that's
an
exciting
job
and
I've
been
involved
with
the
project
since
fall
of
2014.
So
back
before
the
communities
was
even
GA
and
in
my
spare
time,
I
play
saxophone
and
I
hand
engrave
brass
instruments.
So
if
any,
but
he's
a
musician
like
you
know,
let's
talk
afterwards.
Wait,
that's
not
what
you're
here.
A
For
so
the
the
architectures
special
interest
group
has
gone
through
a
bit
of
a
a
lifecycle
evolution
in
the
sense
they
when
we
first
formed
I,
think
there
was
a
notion
that
this
this
was
sort
of
the
ivory
tower
architect
approach
where
this
would
be
a
group
of
people
that
would
sit
in
a
room
and
talk
about
architectural
decisions
and
all
that
and
over
time.
What
has
really
happened
and
involved
is
that
when
you
concentrate
too
much
decision-making
authority
in
one
place
or
in
a
certain
group
of
people,
it
leads
to
burnout.
A
It
leads
to
a
lot
of
really
negative
outcomes,
and
so
one
of
the
core
values
of
kubernetes
as
a
project
is
to
distribute
decision-making
as
close
to
the
people
doing
the
work
as
possible
and
so
cig
architecture.
Over
the
last
year,
we
really
thought
about
what
what
that
would
look
like
what
are
the
ways
in
which
we
can
distri
decision-making
closest
to
the
people,
doing
the
work,
which
is
other
SIG's
again,
those
the
vertical
SIG's
like
API
machinery
and
storage,
networking
and
so
forth.
A
So
our
our
role
is
really
more
around
guidance
and
also
a
few
specific
things
that
we
want
to
keep
an
eye
on
over
time,
because
essentially
kubernetes
part
of
the
value
and
power
of
it
is
that
when
you
approach
the
API,
you
know
what
you're
gonna
get
it's
a
very
specific
style
of
API.
It
has
very
well-known
conventions,
and
one
of
the
one
of
the
things
that
we
want
to
make
sure
that
over
time
is
that
we're
keeping
an
eye
on
that
evolution
and
making
sure
it's
consistent
and
that
it
makes
sense.
A
A
A
A
You
know
I'm
I'm,
doing
my
own
community
service
and
then
you
go
and
try
and
deploy
your
workloads
to
it,
and
it
simply
doesn't
work
because
your
implementation
of
that
is
not
consistent,
so
having
a
really
consistent
way
to
run
workloads
across
any
cloud,
any
implementation
of
kubernetes,
be
it
on
Raspberry,
Pi
or
in
gke
or
wherever.
That
is
that
consistency
is
really
fundamental
to
building
trust
with
the
people
that
use
communities
all
of
you
and
all,
if
you're
a
reseller
or
something
that
you're
customers.
A
So
that
is,
that
is
really
core
to
the
ethos
of
the
project.
Is
maintaining
that
conformance
over
time.
So
really,
when
you
think
about
what
the
definition
of
kubernetes
is
at
the
end
of
the
day,
it's
really
the
conformance
test
right,
because
if
it
passes
the
conformance
test,
then
it's
in
and
if
it
and
it's
not
part
of
a
conformance
test,
then
it's
essentially
out
so
we're
going
to
talk
about
specifically
conformance
testing
a
bit,
but
just
keep
that
in
your
mind
as
a
thing,
so
architectural
renderings
or
another
thing
we
occasionally
do.
A
You
know
this
is
what
the
nucleus
or
the
project,
looks
like,
and
here's
what
the
API
ORS
look
like
and
all
that
we
haven't
done
as
much
of
that
and
I'm
kind
of
sad,
because
I
feel
like
that's
something
that
the
community
could
use.
More
of.
So,
when
I
ask
all
of
you
to
volunteer
later,
anybody
who
wants
to
get
on
that
I'll
I'll
definitely
welcome
to
help
design
principles
and
deprecation
posi
design
principles
is
really
again
talking
about.
What
is
what
do
we
do
when
we
create
an
API?
A
A
That's
because
this
is
part
of
our
covenant
of
trust
with
our
community
having
a
really
sane
deprecation
policy
impacts,
all
the
the
users
in
the
in
the
field
and
how
they
support
their
workloads
and
essentially
minimizing
disruption
with
installations.
So
we're
trying
to
always
keep
an
eye
on
when
we're
when
we're
going
to
deprecated
something.
A
So
we
manage
a
few
processes.
This
is
again
those
cross-cutting
things.
I
talked
about
before
API
review
process
is
a
set
of
skilled
reviewers
who've,
been
with
the
project
for
quite
some
time,
and
essentially
their
job
is
to
look
at
the
implementation
and
make
sure
that
it's
consistent
with
the
API
conformance
guidelines
and
really
going
deeply
into
these
these
designs
to
make
sure
that
they're,
you
know,
is
this
an
API
that
belongs
in
tree
or
out
of
tree?
Would
this
be
better
served
as
a
CR
D?
All
those
things
are
really
a
human
process.
A
We
there's
no
there's
no
way
to
run
a
code.
You
know
code
test
against
this
and
say
yeah.
This
is
a
good
API
or
not.
It
really
requires
expertise
and
people
who
have
seen
a
lot
of
kubernetes
api
s
and
they've
gone
in
and
looked
at
the
code
enough
that
it's
like
yeah.
This
seems
right,
or
this
doesn't
seem
right
and
and
so
earlier
today.
A
I
was
sad
that
Daniel
Smith
one
of
the
people
is
actually
one
of
the
few
handful
of
API
reviewers
did
a
live,
API
review
over
in
the
Google
lounge
and
and
and
nobody
was
really
watching
and
I
was
like
wow.
This
is
such
a
missed
opportunity,
because,
if
I
think,
if
people
saw
it
that
the
process,
it's
really
fascinating,
so
there
are
going
to
be
some
more
of
those
live.
Api
reviews
just
so
just
check
over
there
and
there's
there's
a
board
but
I.
A
A
One
of
the
painful
parts
of
this
is
that
you
really
need
to
look
at
the
implementation
of
something
like
a
pod
and
write
test
cases
for
everything
that
a
pod
can
do
and
just
like
think
about
that
for
a
bit
and
and
think
about
what
that
equates
do
to
test
coverage.
It's
a
lot
of
work
and
it's
important
work,
and
it
is
something
that
we
definitely
need
more
help
on
design
documentation
management
is
really
again.
We
need
people
documenting
these
things.
A
A
lot
of
the
the
core
concerns
of
architecture
lives
in
people's
heads,
I
mean
this
is
like
you
all
work
at
companies,
probably
where
somebody
like
you
know
you
run
into
a
problem,
you're
looking
at
the
code
and
there
and
you
ask
the
person
next
to
you
like
what
is
this
like?
What
and
the
person
says?
Oh,
you
need
to
go
talk
to
Jane
she's,
the
one
that
wrote
the
code
like
I,
don't
really
understand
it,
but
she
can
fill
you
in
on
what
this
is
doing.
A
Literally
kubernetes
has
some
of
these
things
as
well,
where
we,
these
things,
live
in
people's
heads
and
we
need
to
get
it
into
documents
and
then
again,
the
percussion
policy
management
is
making
sure
that
we're
not
doing
disruptive,
deprecation
and
I
would
say
that
just
in
terms
of
deprecation
kubernetes
is
surprisingly
resilient
in
terms
of
beta.
What
we
call
beta
a
lot
of
beta
features,
don't
get
wildly
changed
between
beta
and
GA,
which
is
really
cool
and
I.
A
So
we
talked
about
governance
before
a
cig
is
essentially
a
group
of
people
mobilized
around
a
subject
matter
area
and
then
they
collaborate.
So
one
of
the
ways
that
these
groups
make
sense
out
of
the
collaborationist
are
what
are
called
sub
projects,
and
so
what
you
can
think
of
in
terms
of
a
sub
project
is
these:
are
groups
of
people
that
mobilize
and
quote
unquote
own
code.
A
A
This
is
something
where
we
are
the
the
sole
approvers
where
there's
I
think
five
people
in
the
API
review
or
approver
poll
it
may
be
more
than
that
now,
but
essentially,
as
part
of
that,
that
some
project
is
to
not
only
just
look
at
the
code
make
sure
it's
consistent.
You've
managed
to
the
roadmap
is
to
document
those
design
principles
and
make
sure
that
that
document
is
a
living
document,
because
the
API,
the
way
we
think
about
API
is
is
always
evolving.
A
The
trick
is
that
in
any
step
in
the
evolution,
you
don't
want
it
to
wildly
deviate
from
the
prior
step.
I
mean
if
you
look
at
how
api's
are
implemented
from
you
know,
version
1.2
to
now
there's
significant
differences,
there's
a
lot
of
ways
that
things
are
thought
about
differently,
but
there's
a
lot
of
ways
that
things
are
very
much
the
same.
So
it's
really
you
don't
want
to.
A
If
you
could
rewind
time
and
look
at
look
at
something
you,
it
still
should
make
sense
if
you've
never
seen
it
before
so
part
of
it
is
to
that
we
want
to
document
and
involve
the
system
architecture,
and
this
is
really
thinking
about
the
best
practices
around
how
we
implement
and
again
extension
patterns.
And
you
know
what
are
we
going
to
do
for
you
know
plugins,
and
how
do
we
deal
with
extending
the
api's?
All
that
stuff
is
really
just
the
API
and
architecture
groups
are
working
very
closely
around
around
that
problem
domain.
A
Another
one
is
code
organization,
so
this
sub
project
is
really
focused
on
dealing
with
the
minutiae
of
where
does
code
live,
what
needs
to
be
vendored
any
branching
strategies,
so
there's
been
different
attempts
to
create
features
in
their
own
feature
branches,
and
that's,
as
some
you
know,
there's
probably
a
there's,
a
lot
of
pros
and
cons
to
feature
branches.
It's
great
because
you
have
a
unit
of
work,
that's
essentially
cordoned
off
to
to
tinker
with,
and
you
don't
necessarily
have
to
to
worry
about
a
lot
of
collisions
of
code
and
whatnot.
A
But
the
downside
is
that
at
some
point,
you're
gonna
have
to
merge
back
into
the
main
code
base
and
you
get
into
a
lot
of
merge
conflicts
and
and
all
that.
So
how
do
we
do
that
in
a
really
sane
way,
partly
because
when
you
are
working
on
a
feature
right
now
for
the
most
part,
you're
just
committing
directly
to
master
and
so
there's
no
real
feature
in
master
per
se?
It's
just
a
bunch
of
code.
A
So
when
the
release
team
goes
to
look
at
what's
going
to
be
in
a
in
a
cut
of
a
release,
they
don't
actually
have
the
ability
to
revert
a
feature
per
se,
because
anything,
that's
in
master
has
already
been
merged
and
anything
that's
come
on
top
of
it
would
have
to
be
untangled
and
whatnot.
So
it's
not
really
feasible
to
to
revert
features
that
have
already
gone
in,
so
branches
are
a
way
to
to
sort
of
cope
with
that.
But
again
it
has
its
own
special
things
again.
A
A
So
logistics
for
the
group,
we
have
a
slack
channel
in
the
community
slack
if
you
haven't
signed
up
for
that.
Please
do
there's
also
a
mailing
list
that
we
maintain
and
we
meet
bi-weekly
on
Thursdays
immediately
following
the
community
meeting
and
I
will
admit
that
we
are
terrible
at
handling
EU
time
zones
and
I
am
deeply
deeply
sorry
for
that,
it's
at
an
extreme,
extremely
late
time
for
European
time
zone.
So
yeah.
A
Yes,
it's
bedsore
work
more,
unfortunately,
I
don't
know
what
time
it
is,
but
it's
like
1:00
in
the
morning
or
something
terrible,
but
that
is
something
that
we're
trying
to
tackle
and
do
better
a
job
at
the
release.
Team,
for
example,
has
you
time
friendly
meetings
scheduled
as
well?
So
ideally
we'll
get
better
at
that,
but
right
now,
unfortunately,
we're
cating
to
the
Pacific
time
zone.
The
USA
this
bit
link
here,
the
the
Kate
search
video
will
bring
you
to
all
the
sleep
inspiring
videos
of
your
all
of
our
meetings.
A
It's
definitely
good
if
you're
having
trouble
sleeping
I
think
you
could
just
watch
those
and
you
would
never
have
a
sleepless
night
again
and
really
truthfully
seriously.
There's
a
lot
of
good
stuff
there
and
it's
a
good
way
to
see
how
we
organize
our
meetings.
Our
chairs.
We
currently
have
five,
which
is
fantastic.
We
started
with
two
and
now
are
up
to
five
Brian.
Grant
who
couldn't
be
here
is,
is
you
should
just
like?
A
Let
me
segue
and
riff
here
for
saying
you
should
come
to
Sagarika
texture
meetings,
just
to
hear
Brian
talk,
because
he's
literally
the
architect
of
many
things
that
Google
has
internally
as
part
of
the
infrastructure
and
so
he's
one
of
the
people
that
was
responsible
for
the
original
design
of
kubernetes
he's
responsible
for
a
lot
of
the
API
design
in
borg
and
and
omega.
So
literally,
you
can
come
to
this
meeting
and
and
hang
out
with
one
of
the
one
of
our
brightest
engineers
in
the
world.
A
Truly
amazing
and
in
fact
everybody
on
this
list
is
just
dynamite,
except
for
me,
I
take
notes,
but
you
know-
and
so
this
is
a
great
group
of
people
we
try
and
keep
really
inclusive
meetings.
We
were
trying
to
to
make
sure
that
everybody
gets
heard
and
that
people
are
welcome.
So
you
all
are
welcome.
I
would
love
to
see
in
these
meetings.
A
So
on
that
note,
participation,
SIG's
are
only
as
good
and
as
effective
as
the
people
that
show
up
and
I
really
want
to
emphasize
that
it's
a
sig
is
only
you,
and
so
when
we
are
doing
these
things
when
we're
keeping
an
eye
on
these
important
concepts,
literally,
it
comes
down
to
who
shows
up
for
the
meeting
who's
there
to
discuss
it
and
who's
to
do
the
work.
So
when
we
gather,
as
as
a
community
for
Q
con
I'm,
always
hoping
that
somebody
in
this
audience
will
be
like
wow.
This
sounds
interesting.
A
In
this
room
and
again
I
apologize
for
the
timezone,
it
kills
me
a
little
bit
but
come
to
our
meetings
and
just
listen
or
participate
in
any
way
you
feel
like
you
can,
so
we
also
for
those
people
who
can't
attend
the
meetings.
The
mailing
list
is
very
active.
We
try
and
keep
discussions
really
lively
and
an
inclusive
there
as
well.
A
There's
always
something
you
can
do.
My
my
first
contribution
to
kubernetes
many
years
ago
was
simply
just
showing
up
and
taking
notes
to
the
community
meeting
it
doesn't
have
to
be
you
don't
have
to
be
a
wizard.
You
can
literally
just
be
a
person,
who's,
interested
and
passionate
and
eventually
you'll
find
your
way
to
the
right
thing.
So
again,
the
big
thing
here
is
speak
up.
Share
your
ideas
share
your
thoughts.
A
Everybody
in
this
room
probably
has
some
bit
of
information
in
your
experience
or
your
mind
that
this
project
is
desperately
searching
for
I
can
almost
guarantee
it.
There's
something
you've
seen
there's
something
you've
touched,
there's
something
you've
created
that
informs
what
we're
doing
and
we're
missing
it,
and
how
do
we
get?
That
is
to
bring
you
into
to
share
that
information
with
you
so
and
once
you're
involved.
A
Then
you
can
do
things
like
issue
triage
or
PR
PR
reviews
or
any
kind
of
just
management
of
all
this
information
that
we
have,
because
really
sick
architecture
is
the
keeper
of
this
institutional
knowledge.
This
information,
how
do
we
do
things?
How
do
we
make
sure
that
we
do
the
the
things
the
same
way
in
five
years?
We
are
really
the
group
of
people
that
is
responsible
for
that
sort
of
long-term
view.
It's
three
six
eight
releases
out,
so
I
really
feel
that
it's
important
to
constantly
be
thinking
about
the
next
layer
of
leadership.
A
The
next
layer
leadership.
Is
you
so
I
really
want
you
to
all
know
that
you're
welcome
and
that
there's
no
barriers
to
entry
so
is
really
all
I
have.
This
is
just
a
deep
dive.
It's
a
not
a
deep
dive.
It's
an
overview.
We
do
have
a
deep
dive
tomorrow
tomorrow
morning
and
Tim
Sinclair
who's
been
with
the
project
for
a
long
time,
will
be
doing
that
and
I
highly
encourage
you
to
go
there
and
listen
to
his
take
on
it
as
well.
A
B
Hi,
you
talked
about
the
protecting
deprecation
policy
I
faced
with
issue
when,
since
one
year,
you
realize
like
four
versions
or
five
version
of
kubernetes
and
documentation
for
my
current
version,
which
is
in
production,
are
deprecated
and
no
more
available,
and
it
makes
a
lot
of
issue
for
my
production
is
there
any
kind
of
steps
have
to
upgrade
or
duplicate
alt
version.
I
mean
I,
didn't
saw
something
like
this
yeah.
A
So
technically,
the
support
cycle
for
releases
is
three,
so
you've
got
the
release
and
play
in
the
prior
two,
but
what
we
do
just
as
a
policy
we
try
and
first
four
major
vulnerabilities
or
impactful
problems.
We
will
send
patches
back
several
versions
more.
It's
not
technically
part
of
the
deprecation
policy.
In
theory
that
you
know
the
three
the
three
window
is
done,
then
we
we
don't
have
to
do
that,
but
we
always
try
and
be
very
diligent
about
it
in
terms
of
the
upgrade
cadence.
A
This
is
something
that
we
we
definitely
acknowledge
is
it
is
hard
I
mean
for
an
enterprise.
Nine
months
is
not
long
and
especially
to
burn
through
three
versions,
and
we
we
Google.
We
struggle
with
this
too,
that
we
want
to
make
sure
that
we're
know
producing
quality
releases
for
everybody
in
so
there's
been
talk
about
an
LTS
type
approach
to
this,
and
that
has
its
own
like
really
difficult
issues
as
well
in
terms
of
support
and
and
how
do
we
do
that
and
each
release
team
disbands
after
every
release?
A
C
A
So
in
case
you
hear
the
question
is
what
sir,
what's
the
time
commitment
associated
with
being
a
contributor
to
this,
it
can
be
as
much
or
as
little
as
you
want.
Some
rolls
are
extremely
intense.
The
release
leader
role
is
probably
the
most
intense,
but
just
being
a
reviewer
literally,
you
could
spend
an
hour
a
day
and
review
in
triage,
PRS
and
issues,
and
that
would
be.
That
would
be
huge.
A
That
would
take
it
like
a
huge
amount
of
time
out
of
the
aggregate
amount
work
so
as
little
or
as
much
time
as
you
want
and
in
terms
of
your
history
to
be
able
to
be
at
that
point,
I
would
say
if
you've,
if
you're
familiar
with
using
communities-
and
you
understand
the
design
concepts
about
how
it's
actually
constructed
and
you
can
basically
troubleshoot
a
cluster
or
or
deal
with
you
know
what
that
means.
You're
gonna
immediately
be
in
a
position
where
you
can
help
yeah
for
sure.
Thank
you.
D
Hey
I
have
a
question,
so,
let's
imagine
of
a
situation
what
we
have
idea
of
introducing
some
feature
which
potentially
will
touch
like
signal:
six
scheduling,
maybe
storage
and
so
on.
So
what
would
you
recommend
like
to
bring
it
directly
to
cigarete
lecture
or
start
discussing
it
in
a
mean
way?
Individual
6.
A
Say
that
the
idea
is
go
as
close
to
the
people
that
will
be
coding
it
as
possible.
So
if
you're
gonna
do
an
in
storage
implementation,
definitely
go
to
6
storage
and
get
that
first
take
on
it
because
well,
one
simple
way
is
just
look
at
the
code
base
and
see
who
owns.
Who
are
the
owners
for
the
areas
that
you
want
to
touch
and
those
are
the
first
people
to
contact
because
they're,
eventually,
no
matter
what
you
do
are
going
to
have
to
be
the
approvers
for
the
code,
and
then
we
have
a
process.
A
B
B
B
A
D
A
So
horizontal
SIG's
are
mainly
concerned
with
things
that
cross
different
parts
of
the
organization,
but
not
the
codebase.
So
when
there
are
areas
that
those
two
collide,
the
release
team
being
a
big
one,
you
will
actually
have
people
from
one
sig
attend
the
meetings
to
the
other
and
in
many
cases
like
myself,
I'm
I'm
a
hinge
point
between
some
of
those
things.
A
So
this
is
something
we
actually
have
to
watch
out
for
because
some
people
are
API,
reviewers,
sig,
chairs,
sub
project
owners
and
literally,
if
they
got
run
over
by
a
bus,
we'd
be
in
a
really
bad
shape
like
they
would
take
a
lot
of
a
lot
of
that
knowledge
with
them.
So
again
we
want
to
spread
that
load
out
and
have
more
people
involved
in
an
attending
other
SIG's,
because
they're
interested
in
finding
those
cross-project
things
to
fix
and
identify.
Did
that
answer
your
question?
Okay,
one
more
question,
I
think
we're
done.
A
A
Do
did
you
raise
your
hand,
no
okay,
all
right
well,
if
I'm
around
and
I'll
be
here
all
week.
So
if
you
have
questions,
let
me
know
and
I'm
on
slack
as
well.
Jada
Mars!
So
thank
you
all
so
much!
Oh!
No!
Hopefully
I
haven't
all
been
staring
at
that
while,
as
I've
been
talking
cuz,
it's
kind
of
trippy.