►
From YouTube: SIG Interoperability Meeting - Oct. 20 2022
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
A
B
A
A
B
About
yeah
I
I
saw
the
the
agenda
for
the
community
meeting
is
usually
4
P.M
for
the
winter
time.
C
B
I'm
not
sure
because
because
we
we
could
wear
team
members
lives
in
China
and.
B
Have
the
summer
time
and
winter
time
so
actually
we
are,
we
are
not
snowing.
What
exact
time
are
you
leaving
to
eat.
C
B
D
D
So
we
don't
really
have
other
agenda
items
this
morning,
but
we're
just
here
to
hear
about
Cube
villa
which
I'm
very
excited
about
I
think
this
may
be
in
some
ways
related
to
this
intent
based
pipelines,
thing
that
we've
talked
about
a
handful
of
times
in
this
in
this
venue
and
so
I'm
really
exciting,
really
excited
so
without
without
further
Ado
don
fog.
Would
you
like
to
tell
us
a
little
bit
about
kubella.
B
Yeah
cool
actually
is
there
any
thing
we
would
like
to
discuss
about?
If
not
I
I
will
go
on
with
the
presentation
today.
B
Okay,
okay,
we
can
learn
from
each
other
yeah.
It's
actually
my
first
time
to
share
cuvela
with
with
people
from
other
communities,
so
actually
I'm,
also
a
bit
nervous
and
my
English
is
not
very
good.
So
I
will
try
to
deliver
my
idea
as
clear
as
possible.
So
if
there
is
any
questions
you
can
just
interrupt
me
and
we
can
stop
there
and
discuss
more
about
it
yeah.
B
Okay
thanks:
okay,
thanks
and
can
you
see
my
screen
now?
I
can
yeah
okay.
B
So,
let's
start
with
the
share
of
cookware
today
and
my
name
is
indah
and
today
I
will
share
kubella
with
my
colleagues
named
fog
and
we
are
the
kubella
maintainers
from
Alibaba
cloud,
and
currently
we
are
focusing
on
building
the
application
platform,
which
is
the
kubela
insights,
Alibaba
cloud
and
we
are
trying
to
make
it
make
it
more
functional
and
let
more
users
to
adopt
it
and
we
are
trying
to
continuously
improving
it
and
make
it
better
and
better
and
also
I
have
seen
that
there
is
another.
B
There
is
two
other
members
of
kubela
in
the
meeting
room
here
is
Jambo
and
the
and
ueda,
and
they
are
also
from
the
same
team
and
actually
we
also
have
a
community
meeting.
So
by
usually
we
only
have
a
bi-weekly
talk,
so
the
content
of
our
community
meeting
is
more
of
incremental
matters
and
today
it's
our
first
time
in
the
CD
foundations
community
meeting,
so
I
would
like
to
share
the
overview
of
the
kubera.
But
there
is
a
lot
of
details
behind
this
share.
B
So
if
there
is
I,
I
actually
do
not
have
a
general
idea
of
what
people
from
CD
Foundation
like
and
what
you
are
focusing
on,
but
since
school
Bella
is
a
relatively
large
project.
So
so
there
are
many
different
areas
we
have.
We
have
been
looking
into.
So
if
there
is
any
specific
area
or
techniques
you
like
to
have
more
details
for
actually
we
are
very
happy
to
have
more
discussions
and
sharings
or
even
on
other
community
meetings.
B
We
can
share
more
details
for
this
specific
Fields,
so
today
it's
I
I
would
like
to
just
be
a
start
for
the
sharing
of
covella
and
I
hope.
This
can
make
us
to
to
cooperate
in
the
community
better
and
also
we
can
improve
each
other
better
and
better.
So
so
that's
the
general
introduction
for
the
today's
share
and
let's
move
on
so
the
outline
of
the
talk
today
includes
several
parts.
B
So
first
of
all,
I
will
give
a
very
very
short
description
for
what
cookware
is
and
then
I
will
go
into
some
details
about
how
cool
weather
works
and
especially
for
how
we
design
and
the
the
general
principles
for
Designing,
covella
and
implementing
it,
and
this
part
will
contains
a
lot
of
detailed
techniques
and
after
that,
I
will
actually
fog
will
give
us
a
demo
presentation
for
for
playing
with
kubera.
Actually
it's
it's
just
a
simple
practice
for
using
Google
to
do
the
application,
delivery
and
management.
B
So
let's
go
to
the
first
part,
the
first
parts,
so
I'm
I'm,
not
I,
do
not
know
if
you
guys
have
been
looking
into
Google
for
for
from
which
time,
but
since
kubera
is
developing
very
fast
and
so
even
like
half
years
ago,
kubera
has
a
lot
of
functions.
That's
today
we
have
lots
of
functions.
That's
one
year
ago.
We
do
not
have
it
completely
so
so
generally,
kubella
is
a
modern
software
platform
focusing
on
application
delivery
and
recently
we
are
also
adding
operating
capabilities
for
application.
B
So
generally
we
are.
We
are
working
around
the
application
itself
about
how
to
define
applications
and
how
to
organize
the
applications
and
deliver
deliver
them
to
to
multi-cloud
environments,
and
also
we
focus
on
the
the
date
you
operating
part,
which
means
that
the
Opera,
how
the
application
runs
and
if
there
is
any
exceptions
for
the
applications.
So
that's
what
kubera
cares
about
and
besides
one
of
the
most
important
thing
in
Cuba
is
that
it's
it's
a
program.
B
It's
organized
the
resources
that
it's
want
to
manage
in
a
highly
programmable
way,
which
makes
it
very
extensible
and
use
a
and
very
friendly
for
Community
developers
to
make
contributions.
For
example,
we
can
make
arbitrary
extensions
and
Integrations
to
a
third-party
systems,
as
we
listed
here,
such
as
the
Prometheus
and
terraform
and
other
other
lots
of
Open
Source
projects,
and
also
we
are
focusing
on
the
continuous
delivery
part
and
we
have
made
some
practices
for
integrating
with
the
CI
pipelines
such
as
Jenkins,
and
also
the
gitlab
or
GitHub
at
GitHub
actions.
B
So
this
is
a
very
brief
overview
of
what
Google
is
and
then
I
will
go
on
with
some
technique,
details
and
designs
and
principles
for
the
kubera
okay.
So
the
first
part
of
the
designs
is
about
the
application
delivery,
which
is
actually
what
covella
is
rooted
from
so
at
first,
the
equivalent
is
more
of
focusing
on
delivering
application,
and
one
of
the
most
exciting
things
in
Cuba
to
deliver
to
deliver
application
is
that
we
use
a
high
level
abstractions
to
model
the
application.
B
So,
as
you
can
see,
that's
in
Cuba
we
have
a
very
core
unit
called
the
application.
It
is
designed
to
model
a
fully
functional
microservice
unit,
for
example,
if
you
want
to
have
your
own
website,
the
the
website
itself
is
can
be
seen
as
a
application,
but
to
make
that
website
works,
you
might
need
some
different,
different
components
like
you,
you
might
need
you
might
need
to
have
some
front-end
service,
the
backend
service
and
also
the
the
database
to
serve
the
data.
B
So
at
this
point
you
can
organize
your
application
with
different
components,
and
each
component
will
contain
a
running
workload
that
provides
specific
functions
like
the
front-end
service
or
the
database,
and
these
components
are
relevant
with
each
other
and
they
might
need
to
call
each
other
to
provide
a
fully
full
services
to
the
customers
or
users
and
Beyond
the
component
itself
to
make
those
components
Works.
Usually
we
do
not
only
have
those
running
containers
or
ports
on
kubernetes.
We
also
have
some
auxiliary
resources.
We
call
it
straight
the
operational
auxiliaries.
B
This
includes
like
storage
or
Gateway,
that
can
provide
some
some
basic
infrastructure
capabilities
that
helps
the
running
workload
to
provide
the
services.
So
that's
how
we
Define
the
basic
application,
so
all
all
the
resources
and
are
organized
into
the
components
and
those
those
relevant
components
composed
the
application
itself.
So
so
the
application
is
what
kubella
cares
about,
and
the
following
capabilities
are
all
working
for
that
application
and
as
for
the
as
for
the
abstraction
layer,
we
use
the
qlan
programming
language
to
make
abstractions.
B
So
actually
in
Cuba,
there
is
a
lot
of
resource
templates,
which
we
called
X
definitions.
For
example,
as
for
the
as
for
the
web
service,
you
might
need
to
run
some
ports
or
containers
in
kubernetes,
and
we
usually
use
a
deployment
kubernetes
deployment
to
to
deploy
your
image
and
to
model
that
running
workload.
We
can
create
a
components,
definition
called
web
service,
so
the
web
service
component
definition
is,
is
a
queue
template
which
accept
parameters
from
the
application
and
then
render
it
into
the
detailed
deployments
under
under
the
application.
B
So,
in
addition
to
the
web
service
itself,
we
might
need
to
add
some
traits
to
it
to
help
it
to
work
like
we
might
need
some
higher
available
services.
So
we
may
need
that
that
deployment
to
have
multiple
replicas
is
that
that's
how
we
use
the
scalar
trade.
The
scale
scalar
traits
will
Define
the
template
of
modifying
the
original
workload
and
also,
if
you
want
to
expose
your
service
to
outside,
you
might
need
some
Gateway
auxiliaries,
such
as
the
service
object
and
the
Ingress
object.
B
They
can
use
together
with
each
other,
and
this
can
be
bundled
into
another
trade
definition
or
we
call
some
resource
resource
templates
and
the
Gateway
trips
definition
accepts
some
parameters
like
the
the
path
and
the
part
you
would
like
to
use,
and
also
the
underlying
in
Ingress
class,
and
also
the
domain
you
want
to
connect
with.
So
these
parameters
are
exposed
to
upper
layer,
application
users,
so
the
application
layer,
the
application
user,
only
need
to
fill
those
exposed
parameters
to
use
the
underlying
Gateway.
They
do
not
need
to
care
about.
B
B
Those
guys
are
more
for
more
of
focusing
on
how
to
expose
underlying
infrastructure
to
their
upper
users.
So
so,
by
using
this,
this
abstraction
layer
we
can
make
the
a
large
development
team
can
cooperate
better
with
the
underlying
operating
team.
Besides,
the
the
template
itself
is
highly
extensible.
You
can
write
like
arbitrary,
rendering
logic
in
Q
language,
and
then
you
can
just
put
it
in
your
covela
system
and
then
the
system
will
be
extended
so
that
you
can.
The
application
user
will
be
able
to
connect
to
more
infrastructure
capabilities.
B
So
that's
how
the
basic
extensibility
comes
from
okay,
so
after
we
have
done
the
rendering
part,
that
is,
we
rendered
those
parameters
into
the
real
running
resource.
The
next
part
is
that
we
need
to
orchestrate
those
resources,
because,
as
I
mentioned
above
those
components
in
application
are
not
irrelevant,
they
are
related
to
each
other.
For
example,
your
WordPress
application
is
your
WordPress
deployment
might
need
to
be
run
after
the
database
is
ready,
so
the
database
component
should
be
set
up
before
your
WordPress
is
delivered.
So
so
that's
how
we
orchestrate
the
application.
B
We
specify
the
dependencies
between
different
components
and
that
will
tell
the
application
how
those
components
should
be
orchestrated
and
delivered,
and
this
is
one
way
we
can
organize
those
compound
opponents
in
one
application,
except
for
the
dependencies.
We
also
have
a
very
fine-grained
control
capability
for
the
application
delivery
process.
That
is
the
workflow
part.
So
in
workflow
you
can
actually
manually
specify
which
Step
you
want
to
use
and
how
those
steps
are
organized
together.
For
example,
you
can
firstly
apply
your
databases
until
it
is
ready
and
then
you
will
apply
the
WordPress.
B
B
And
we
have
a
very
Advanced
capabilities
for
control,
the
workflow
part.
For
example,
we
can
have
some
conditional
execution
and
also
we
can
have
some
data
data
passing
between
different
steps
and
also
the
workflow
part
supports
parallel
parallel
executive
execution
so
that,
when
you
have
lots
of
components
inside
one
application,
it
can
be
delivered
with
high
performance.
B
Besides,
the
workforce
part
is
also
highly
extensible
extensible
through
the
Q
rendering
templates,
instead
of
rendering
those
those
templates
into
resources.
The
in
the
workflow
part.
We
render
those
templates
into
actions
or
commands
that
will
be
executed
by
the
underlying
clubella
controller,
and
the
kubera
controller
itself
provides
lots
of
a
lot
of
underlying
functions,
for
example,
apply
one
component
or
read
some
resources
from
the
kubernetes
cluster
or
send
messages
through
slab
and
the
upper
layer.
B
Workflow
step
will
be
able
to
leverage
the
underlying
functions
and
organize
them
and
and
make
them
work
together
to
produce
a
higher
level
step.
Workflow
steps
for
the
application,
you
user,
so
the
application
user
will
be
freed
from
carrying
the
underlying
implementations,
but
more
focus
on
what
what
process
they
will
would
like
to
execute.
B
So
so,
depending
on
the
scenario
of
application
user
want
to
use,
there
are
different
level
of
abstractions
and
they
can
they
can
use
any
way
to
organize
them.
And
finally,
we
also
support
the
multi-cluster
deployment.
For
example,
if
you
want
to
deploy
your
engines
into
multiple
kubernetes
clusters,
the
Legacy
way
to
do
it
is
to
like
to
copy
the
application
copy.
The
engines
configuration
and
apply
them
into
different
kubernetes
clusters,
one
by
one,
but
with
the
equivalent
application
itself,
you
can
specify
the
multi-cluster
deploy
strategies.
B
For
example,
you
can
specify
the
topology
to
you
to
specify
which
classes
you
want
to
deploy
to,
and
the
application
will
will
be
able
to
deploy
those
resources
into
different
clusters
at
the
same
time
or
in
order,
and
this
will
help
the
users
to
keep
those
common
configurations
into
one
single
file.
So
that's
the
map,
management
of
those
configurations
will
be
much
easier
and
manageable.
So
if
you
want
to
make
some
updates,
you
do
not
need
to
go
one
by
one.
You
just
add
its
one
application
and
it
will
take
effect
in
all
clusters.
B
So
that's
how
we
do
multicaster
deploy
with
the
application,
and
in
addition
to
that,
we
also
have
some
authentication
for
the
deploy
process.
That
means
we,
we
reuse
the
authentication
mechanism
of
kubernetes
and
that
will
let
the
user
of
application
only
able
to
deploy
resources
under
its
privileges.
B
So
if
someone
wants
to
create
an
application
and
deploy
resources,
that's
beyond
its
privileges,
it
will
be
forbidden
by
the
kubernetes
API
server,
so
the
authentic
the
delivery
process
is
authenticated
and
secured,
and
also
the
multi-cluster
deploy
supports
all
kinds
of
cloud
providers
and
also
we
even
support
Edge
kubernetes,
which
might
have
some
issues
with
the
network
connection
in
which
place.
We
incorporate
the
open
cluster
management
to
support
two
different
ways
for
the
cross-cluster
connection,
including
the
pool
mode
and
the
push
mode
and
okay.
So
that's
all
for
the
application
delivery
part.
B
So
by
far
we
have
been
discussing
about
how
cubilla
defined
application
organized
resources
and
dispatching
them
into
various
destinations
and
also
after
we
we
have
delivered
those
applications.
We
will
be
focusing
on
how
those
applications
runs
and
how
to
how
to
manage
them
and
operating
them.
B
Okay,
so
the
first
first
important
things
for
one
application
is
that
how
it
manages
different
resources,
like
one
of
the
fundamental
rules
for
the
covella
application,
is
that
it
is
generally
a
final
State
oriented.
So
when
the
delivery
process
has
helped
Google
application
to
reach
the
the
desired
State,
the
desired
state
will
be
kept
and
will
be
watched
as
well.
Once
someone
edits
the
resources
and
led
it
to
be
different
from
the
desired
State,
kubera
application
will
be
able
to
find
that
and
bring
it
back
later.
E
B
So
this
is
one
of
the
fundamental
rules
for
Google
applications,
but
also
there
are
scenarios
that
users
do
not
need
this
feature
and
this
feature
can
be
switched
off
as
well.
Besides
the
covella
application.
Also,
it
is
also
responsible
for
recycling
all
the
resources
it's
dispatched,
so
so,
once
the
application
is
deleted
or
upgraded,
the
outstated
resources
will
be
deleted
as
well.
B
There
are
some
cases
the
applications
could
share.
Multiple
applications
could
share
the
same
resource
and
they
will
share
the
control
of
the
resource
and
manage
them
in
manageable
ways.
Yeah,
okay
and
also
Google
application
has
version
controls.
So
if
you
have
delivered
your
application
and
updated
it
and
many
times
you
can
actually
roll
back
to
previous
versions
once
you
find
that
the
latest
delivery
is
is
has
failed,
so
you
can
actually
view
those
history
versions
and
find
out
which
one
is
successful
and
go
to
the
latest
successful
one.
B
So
that
is
a
rollback
action
for
the
application,
and
also
sometimes
you
might
need
to
you-
might
want
to
manually,
publish
your
application
instead
of
let
the
application
publish
itself
once
it's
changed.
So,
with
the
manual
publish
capability,
you
can
edit
your
application
first
and
commit
those
changes
later
and,
for
example,
when
the
changes
are
not
committed,
you
can
actually
use
some
like
CRI
commands
all
the
UI
to
see
the
difference
of
the
current
version
and
the
the
current
spec
of
the
application.
B
B
Besides.
We
also
have
obser
availability
for
the
application
itself.
This
is
achieved
by
integrating
various
community
at
a
virus.
Community
projects
like
the
famous
promises
and
gratner,
and
it
is
also
reached
by
creating
new
component
definition
and
trade
definition
itself,
and
also
the
backgrounds.
The
those
graph
line
promises
can
be
integrated
from
Cuba
add-ons
and
oh
and
you
can
build
them
on
premise
and
also
you
can
reuse
your
cloud
services
from
cloud
providers
like
Azure
or
Amazon
yeah
and
also
after
you
have
set
up
your
infrastructure
for
observability.
B
Covella
application
is
able
to
use
those
trade
and
components
to
declare
which
which
way
you
want
to
use
to
monitor
your
application.
So
besides,
we,
we
also
have
some
basic
Observer
observability
capabilities
from
the
CLI
and
the
UI
as
well.
B
So,
as
the
official
repository
we
have,
we
have
a
report
on
GitHub
called
catalogs,
which
holds
lots
of
existing
add-ons
and
those
add-ons
are
application
templates,
which
is
backed
by
Q
as
well.
You
can
render
those
application
templates
into
application
and
deploy
those
applications
in
the
kubernetes
cluster
so
that
you
can
integrate
other
open
source
projects
like
decks
or
Fox
CD
as
well.
B
So
these
add-ons
are
actually
organized
by
queue
templates
as
well,
and
these
definitions
will
help
the
existing
application
in
the
kubernetes
cluster
to
use
the
capabilities
provided
by
that
teardown.
B
B
F
B
F
Hi
everyone,
my
name,
is
fog,
I'm
glad
that
I
can
give
you
a
quick
demo
today
about
how
cool
runner
can
work
for
your
application.
You
can
deploy
manage
to
observe,
let's
get
started.
So,
let's
start
with
a
single
case.
I
have
two
clusters
called
local
and
product.
I
have
already
managed
them
with
Vera
commands,
so
I
can
use
letter
class
list
to
show
two
clusters.
F
And
I
want
to
deploy
and
inject
to
both
of
the
Clusters.
So
here's
my
application,
yaml,
the
application,
is
also
very
simple.
There's
only
one
component
in
the
application
it's
called
njx
and
its
type
is
web
service.
I
also
change
its
expose
type
to
note
part
so
that
I
can
access
the
ngx
more
directly
and
I.
Have
this
policy
here
called
topology
in
this
policy?
I
specified
that
I
will
apply
the
component
and
Jacks
to
two
clusters:
local
and
product,
and
in
workflow
I
Define?
How
I
can
control
the
deploy
process?
F
F
F
This
command
shows
all
the
resources
behind
the
application,
so
the
first
line
here
is
cluster,
and
after
that
is
namespace,
you
can
see
that
all
the
resources
in
the
application
from
different
cluster
and
namespace
in
this
application.
We
have
this
ngx
deployment
in
two
clusters
here
and
also
we
can
use
this
Vena
status.
Slash
endpoint,
to
show
the
service
to
show
the
service
address
of
the
application.
F
F
F
In
fact,
we
have
some
default
resource
graph
rules
for
the
normal
application,
for
example
we'll
Define
that
after
deployment
will
have
replica
set
and
after
that
we'll
have
pod.
But
if
you
want
to
create
your
own
resource
graph
rule,
that's
totally
fine
with
our
Q
interface,
you
just
need
to
Define
your
resource
rules
in
the
add-on
and
when
the
add-on
is
enabled
all
the
results,
graph
rules
will
be
applied.
F
F
F
F
F
B
Okay,
that's
a
brief
introduction
and
the
demo
for
the
kubella,
and
actually
we
have
more
information
for
the
cover.
For
example,
we
we
have
done
some
load
testing
and
have
shown
that
kubera's
controller
is
is
possible
to
handle
thousands
of
applications
under
limited
resources,
and
you
can
actually
make
some
customized
tuning
to
let
your
Google
app
controller
to
handle
more
applications
under
certain
circumstances,
and
also
here
is
a
brief
overview
for
the
Milestones
of
kubella.
B
And
you
can
see
that
since
the
march
in
last
year,
we
have
just
released
the
version
1.0
at
which
time
we
only
have
the
application.
But
after
one
year
and
a
half
and
we
have
developed,
developed
lots
of
new
features
like
the
workflow,
the
value,
ux
and
also
the
observability,
and
we
are.
We
are
recently
recently
working
on
some
new
features
for
the
workflow
part
and
the
of
the
availability,
and
we
are
making
new
minor
releases
every
three
to
four
months.
B
I
think
yeah
also,
and
there
are
lots
of
users
that
are
using
kubela
and
as
far
as
we
know
that
there
are
some
areas
that
uses
kubela.
There
are
multiple
companies
using
kubela
in
those
areas
like
the
bank
banking
area
and
also
the
car
manufacturers,
and
also
the
Some
Cloud
providers
uses
Cuba
to
build
their
past
platform
and
also
there
are
some
game
companies.
So
as
far
as
we
see
that
some
high-tech
Industries,
like
scuba
a
lot
and
also
here,
is
a
chart
for
how
cubilla
Community
are
evolving
and
so
the
equivalent.
B
There
is
a
lot
of
attractions
to
Cuba
recent
days
and
also
we
are
responding
to
all
kinds
of
issues
and
pull
requests
as
fast
as
possible,
and
we
have
over
hundreds
of
contributors
from
various
countries
and
for
those
thousands
of
issues
have
been
created.
We
have
solved
most
of
them
and
besides,
we
also
have
the
bi-weekly
community
meeting,
which
is
on
Tuesday
and
also
we
have
recorded
each
community
meeting
and
posted
on
YouTube.
B
So
actually,
there
are
also
like
30
times
recordings
on
the
network
and
which
in
which
introduced
the
progress
of
covella
bi-weekly
yeah.
So
that's
all
for
today's
sharing-
and
here
is
the
GitHub
repo
for
kubela
and
also
we
have
our
slack
Channel
and
for
I
think
for
Chinese
users.
More
more
users
who
would
like
to
use
think
talk.
So
here
is
the
com
communicate
tools
that
can
reach
out
to
the
equivalent
team.
B
So
I
think
that's
all
for
today's
sharing
and
if
there
is
any
questions
you
can
just
erase
it
here
and
we
can
discuss
it
and
answer
it.
D
Very
cool,
thank
you
so
much
for
taking
us
through
that
I
have
a
bunch
of
questions
and
I'll.
Try
not
to
monopolize
time
but
I'm
excited.
D
So
one
question
I
have
is
it
sounds
like
the
one
of
the
central
premises
of
this
application
object
is
that
everything
for
a
microservice
should
be
defined
in
either
that
application
object
or
the
associated
Q
files.
For
that
X
definition
and
I'm
wondering
if
there
are
tools
that
you
use
it
seems
like
it
could
get
really
big
like
a
really
giant
file.
I'm
curious,
if
is,
but
does
it
get
really
giant,
and
second,
are
there
tools
that
you
use
to
manage
that
complexity?.
B
Okay,
so
that's
actually
a
very
a
very
critical
question
and
also
we
are
facing
it,
especially
in
a
real
production
environments.
Some
of
the
users
are
also
raising
the
same
question
here,
so
actually
it
is
true
that
the
applications
could
grow
very
big,
especially,
for
example,
when
we
build
those
add-ons.
Some
of
the
critical
question
is
that
there
are
crd
definitions
and
those
definitions
are
usually
very
big
and
also
at
last,
you
see
that
we
use
components
to
model
the
graphene
dashboard
and
the
graph,
not
dashboards.
B
The
behind
data
is
really
big,
like
thousands
lines
of
codes,
so
if
you
put
them
all
into
the
application,
it
will
be
really
really
big,
but
there
are
two
ways
to
solve
it,
so
the
one
one
way
is
that
we
leave
those
complex
things
in
the
Q
files,
so
the
those
definitions,
so
those
large
files
will
only
be
handled
by
the
system.
Operators
and
the
application
user
will
not
handle
it
directly.
B
So
they
will
only
use
those
those
exposed
interfaces
and
definitions
and
the
definition
itself
can
generate
lots
of
codes
under
under
the
application
itself
and
another
way
to
handle.
It
is
that
we
support
special
components,
called
ref
objects.
B
The
Rev
objects
can
use
the
URL
to
to
refer
to
some
resources
outside
the
kubernetes
system,
for
example
from
your
GitHub
repo,
and
so
that
you
can
place
those
large
files
into
some
repository
and
you
do
not
need
to
face
them
in
the
queue
files
or
the
application,
and
you
can
use
the
ref
links
to
to
help
you
handle
that,
but
as
for
the
large
files
itself,
I
think
usually,
if
the
large
files
contain
multiple
Parts
personally,
I
would
suggest
separating
them
into
different
components
or
different,
even
different
applications.
B
So,
but
as
far
as
we
see
that
there
are
users
that
in
our
community
that
have
large
applications
and
the
large
applications
will
truly
cause
some
storage
problem
them,
because
the
application
is
a
crd
and
the
recordings
like
the
application,
revision
or
some
other
related
crds
could
be
really
very
really
large.
So
we
actually
to
handle
the
performance
parts.
We
also
have
some
use
some
compression
algorithm
or,
like
you,
split
those
storage
to
handle
the
performance
problem,
so
the
size
of
the
application
or
the
resources
are
actually
something
we
are.
A
How
we
manage
Q
files
am
I
right,
we
have
provided
several
commands,
such
as
Vela
vet,
valadef,
apply
or,
and
the
validif
edit
and
so
on,
and
we
also
have
lots
of
commands
to
manage
the
version
row
row
pack
mechanism
and
such
as
version
management
mechanism.
So
we
really
provided
the
tool
sets
to
manage
the
Q
files.
B
Yeah
awesome
so
just
for
some
additional
information.
So
if,
as
for
the
managing
your
definition
and
Q
files,
you
can
either
use
the
Valor
command
line
interface
to
to
help
you
to
manage
those
things
in
the
CRI
part,
we
do
some
parsing
and
some
some
some
help
commands
to
help
you
to
manage
those
large
files
and
also
on
the
UI
platform,
which
is
the
value
ux.
B
You
can
also
viewing
those
definitions,
that's
in
in
your
browser,
which
can
makes
it
might
be
better
for
editing
and,
besides
so
kubela
itself,
we
are
trying
to
make
the
definition
as
close
to
the
Q
Land
Community
as
well.
So
actually,
we
have
recently
using
the
latest
version
of
the
qlan.
So
one
of
the
way
to
manage
those
steps
missions
and
also
the
add-ons
all
things
in
Cuba
that
related
to
Q.
We
are
making
it
possible
to
use
the
native
Q
tools
to
like
to
do
the
formatting
and
the
syntax
check
so
yeah.
B
So,
therefore,
you
can
leverage
the
queue
tools
instead
of
developers
to
help
you
to
manage
those
things
as
well.
E
D
B
Okay,
so
the
definition
itself,
as
you
said,
the
for
example,
the
web
service
components
definition,
the
definition
itself
only
lives
in
the
control
plan.
It
will
not
be
multi-clustered.
B
So
as
for
the
updates,
that
will
be
another
very
interesting
question:
that's
how
we
use
application
revision
to
store
the
history
history
things.
For
example,
when
you
deploy
your
application,
the
application
revision
itself
will
not
only
store
the
application,
but
also
store
all
the
related
definitions
in
the
revision,
so
that
when
you,
when
the
outside
definition,
changes,
the
application
can
always
have
a
history
tracking
for
the
definition
that
it
uses
in
the
past
when
it's
delivered
the
resources.
So
so
that's
also
a
problem
that
will
cause
the
application.
B
Revision
goes
very
big,
but
in
this
way
you
can
have
a
very
you
can
have
a
snapshot
or
a
very
static
storage
for
the
history
version
of
your
definition
and
your
application.
D
B
Yeah,
so
so
at
so,
as
you
have
have
seen
that
the
application
and
application,
also
the
application
itself,
can
manage
resources
across
different
clusters,
so
I
think
that's
the
delivery
part,
but
for
the
rendering
part,
all
the
rendering
process
we
have
done
on
the
single
Hub
cluster.
So
so
the
Q
part
will
only
live
in
one
cluster
and
also
the
definitions
will
will
only
be
used
in
one
cluster
as
well.
The
remote
clusters
will
not
interact
with
the
the
upper
layer
definitions.
B
B
A
Yes,
not
not
really,
once
an
application
has
been
deployed
and
running
smoothly,
it
won't
be
affected
immediately
when
the
definition
is
updated.
It
will
trigger
the
update
when
the
application
spec
has
changed,
so
any
that
NAX
definition
change
won't
affect
the
running
application.
Just
the
effects
at
the
next
deliver
process.
B
Yeah,
so
so
I
can
keep
give
a
example
for
that,
for
example,
if
you
have
all
already
delivered
like
100
application
in
your
cluster
and
and
you
want
to
try
to
edit
the
definition
since,
though
the
100
application
has
been
successfully
delivered
and
the
added
to
the
definition
itself
will
not
directly
trigger
those
100
applications
to
be
redelivered,
they
will,
they
will
stay
there
and
not
changed,
but
the
next
time
they
are
updated.
They
will
use
the
latest
definition.
B
Yeah,
it
seems
seems
you
are
very
interested
with
the
the
rendering
path
with
q
and
actually,
we
are
continuously
communicate
with
the
Q
team,
because
we
are
using
some
latest
features
and
and
Q
also
have
some
bugs
for
the
latest
features.
So
so
we
are,
we
are
having
meetings
and
upgrading
those
underlying
infrastructure
as
well.
Foreign.
D
Awesome
well,
I
super
appreciate
you
all
coming
by
and
giving
us
talk
about
kubella.
This
has
been
super
interesting
and
very,
very
tied
into
the
things
we
do
here
on
the
interoperability
group.
B
D
A
B
You
Justine
thank
you
if
you
I'm
not
sure,
if
is
it,
okay
for
us
to
share
the
materials
or
the
PowerPoint
slides
to
the
to
other
community.
B
It
okay,
so
so
because
because
the
I
think
there
is
some
material,
that's
contained
in
the
in
the
presentation,
but
I
give
it
very
fast.
So
if
you
want
to
have
some
detailed
information,
you
can
go
back
to
the
slides
and
I
I
think
it
will
provide
more
information
for
that.