►
From YouTube: Layer5 Community Meeting (February 18th, 2022)
Description
Agenda:
[Ashish] Meshery: Review of multi-context support
[Unnati Chhabra]
- Layer5 at OpenForce 2022
- Add OpenForce on the programs page https://layer5.io/programs
- Write-up: suitable as a description when you make a post under Events collection. https://layer5.io/community/events
- [Shebuel]My Layer5 Event Task
- Confirmation of mentors, and minor projects / open issues
[Bami] Layer5 at SheCodeAfrica
Find out more about Layer5 and its open source work at https://layer5.io/community!
A
A
Okay,
so
a
meanwhile,
we
always
begin
this
call
with
the
introduction
of
our
newest
members.
So
is
there
anyone
on
the
call
who
is
attending
our
community
call
for
the
first
time,
even
if
you
have
attended
any
other
calls
throughout
the
week
feel
free
to
introduce
yourself
on
this
one?
We
have
a
lot
of
new
members
here
from
what
I
can
say
is
this:
your
first
community
call
with
us.
A
C
C
D
C
D
D
C
D
C
C
A
A
E
Okay,
so
assuming
my
screen
is
visible,
so
recently
our
pull
request
was
merged
and
the
feature
that
was
introduced
was
managing
multiple
context,
so
managing
multiple
clusters
from
meshri,
and
now
I
will
go
over.
What
are
the
caveats
of
it?
What
are
the
things
that
are
still
required
from
the
ui
and
what
are
we
doing
at
the
back
end?
What
has
changed
and
all
in
all,
so
the
default
behavior?
E
Previously
it
was
that
you
upload
a
cube
config
inside
of
the
settings
page,
you
upload
a
cube
configure
and
when
you
upload
a
cube
conflict
inside
of
your
cube
config,
you
have
something
known
as
a
current
cluster
current
context.
Wait
a
minute.
My
pop-up
has
okay
yeah,
so
something
known
as
current
context.
So
whenever
you
apply
any
operation
from
let's
say
you
from
life
cycle,
or
maybe
you
deploy
a
pattern
or
perform
any
operation
on
a
cluster.
That
cluster
is
by
default.
E
The
current
context
that
inside
of
your
cube
config
now,
the
support
that
was
added
was
to
make
sure
that
what,
if
you
have
let's
say,
11
contexts
now
and
because
you
config
only
supports
one
of
them
being
a
current
context,
because
the
client
supports
one
context
at
a
time.
So
you
can
only
perform
one
operation
and
basically
you
can
only
perform
operation
on
one
cluster
at
a
time.
E
So
that's
why
you
have
only
one
cluster
as
current
current
context,
if
you
want
to
switch
there
is
there
are
commands
like
queue,
config,
cue,
cutter,
config
and
then
use
context
and
all-
and
you
have
to
keep
changing
context
and
do
that
now
the
default
behavior
right
now
the
default
behavior
before
this
pr
was
to
was
to
do
exactly
how
cube
ctel
was
doing
it,
perform
the
operation
on
the
current
context.
But
inside
right
now
I
have
inside
of
my
coupon.
E
Yeah,
it
was
this
one,
so
here
I
have
two
contacts:
one
of
them
is
mini
cube2
and
one
of
them
is
minicube,
and
this
data
is
used
over
here.
So
you
can
see
mini
cube,
2
and
mini
cube
by
default.
As
you
can
see,
mini
cube.
2
is
checked
because
in
my
q
config
that
is
because
that
is
set
as
actually
when
you
load
a
cube,
config
the
correct.
There
are
two
current
contexts
here:
first
is
the
one
in
the
cube
config
and
the
other
is
the
one
in
one
with
meshi.
E
So
when
you
load
a
cube,
config
the
default
one,
the
one,
the
current
context
inside
of
the
queue
control
becomes
the
current
context
of
here
in
measuring.
So
that
means
that
whenever
you
apply
any
operation
because
we
want
to
be
backwards
compatible,
so
we
don't
want
to
break
everything
all
our
existing
apis
and
all
our
existing
apis
are
single
cluster
by
default,
so
they
don't
specify
what
contexts
to
act
upon.
So
what
to
do
in
that
case.
So
in
that
case
we
just
use
the
default
context.
E
E
There
is
extra
thing
that
is
needed
to
be
added
on
the
ui
side.
The
thing
is
that,
instead
of
q,
there
should
be
a
query
parameter.
You
know
any
basically
any
api
that
has
anything
to
do
with
the
basically
and
any
api
that
has
anything
to
do
with
the
kubernetes
cluster
should
have.
Whenever
you
call
that
api,
it
should
be
a
query,
parameter
known
as
contexts
and
there
you
provide,
which
particular
context
you
want
to
apply
that
operation
on
if
there
is
no
query
parameter
named
as
context
by
default.
E
That
would
be
applied
on
your
current
context,
which
in
this
case
is
mini
cube
too,
and
if
you
give
it
basically,
if
you
let's
say
in
this
case,
I
checked
mini
cube,
2
and
mini
cube,
what
the
ui
should
do,
which
is
which
it
is
not
doing
right
now,
the
ui,
it's
not
a
big
change,
the
ui
can
do
it
pretty
easily.
So
editor,
maybe
you
can
take
a
note
of
it.
E
The
thing
that
is
needed
to
be
added
here
is
that
when
I
click
on
these
two
things
at
the
ui
site,
whenever
you
send
an
api
call,
you
attach
that
this
data
in
the
query
parameter
context
so
because
we
have
a
middleware
there
in
our
backend
which
whose
job
is
to
take
all
the
context
from
that
query,
parameter
and
insert
it.
There
insert
basically
means
that
now
every
api
endpoint
can
deal
with
that
data
differently,
which
basically
means
that
now
someone
might
might
have
a
question
about.
E
Are
we
applying
the
operation
sequentially
or
parallelly?
Well,
it's
not
hardcoded
anywhere,
because
every
api
gets
these
active
contacts
as
well
as
this
current
context.
So
it
is
up
to
the
api
how
it
wants
to
handle
these
things
right
now
the
pattern
deployment
point
it
does
it
parallely.
So
basically,
but
we
are
not
making
use
of
that
because,
right
now,
when,
when
I
actually
deploy
the
pattern,
we
are
not.
Let's
say
I
select
these
two
things.
E
This
is
not
being
persisted
and
I'm
not
actually
sending
these
things
in
the
query
parameter
that
things
need
to
be
changed
on
the
ui.
Still
I
can
demo.
So
if
you
don't
select
anything-
and
you
like
like,
if
I
let's
say
select
these
two
things
and
if
I
just
reload
the
page,
because
I
didn't
select
anything
now,
my
mini
q2
would
be
checked,
because
that
is
my
current
context.
E
Okay,
so
now,
if
I
let's
say,
go
over
any
particular
pattern-
and
this
is
a
basic
histo,
installation
profile
is
default,
so
it's
your
pod
and
interest
gateway,
and
if
I
look
at
my
okay,
so
my
current
context
here
here
is
mini
cube2,
so
I
will
quickly
switch
over
to
mini
cube
from
my
cube
petal
as
well.
So
right
now,
as
you
can
see,
there
is
no
istio
part
over
here.
E
So
let's
say
I
selected
a
mini
cube
2
from
here
and
now
I
want
to
install
this
tune
in
that
particular
cluster,
so
I
click
deploy
and
okay
now
my
history
part
came
up
and
also
my
ingress
spot
came
up
as
well.
Now
what
should
happen
right
now
that
this
thing
needs
to
be
changed
in
the
ui
that
if
I
unclick
this-
and
I
click
this-
you
need
to
change
current
context
on
the
fly
from
here.
E
By
sending
a
request
on
to
an
endpoint
which
already
exists,
slash
api,
you
can
go
ping
me
on
slack
in
the
notes
in
the
chat
I'll
go
over
what
the
exact
endpoint
is,
but
when
I
select
mini
cube
here,
what
should
happen
is
that
this
this
should
be
set
as
current
context
or
if
there
is
no
okay.
Now
I
can
talk
about
what
is
current
context
known
as
active
context.
E
After
I
go
over
the
demo
now,
let's
say
I
go
over
my
settings
page
and-
and
I
select
let's
say,
mini
cube
as
my
current
context
now,
any
operation
that
would
be
applied
would
be
applied
in
the
mini
q
cluster.
So
if
I
look,
what
are
the
ports
running
in
my
mini
group
cluster?
There
is
no
skew
port
again
now,
if
I
take
my
h2
install
and
I
deploy
it-
okay,
I
also
here
it
is.
I
am
seeing
my
supports.
E
C
E
Music,
the
reason
we
still
have,
okay,
so
one
of
the
arguments
can
be.
Why
don't
we
have
a
current
context?
We
don't
tell
the,
for
example,
we
know
what
current
context
is.
Let's
say
there
are
the
user
wants
to
apply
something
on
to
the
two
clusters,
so
what
we
are
going
to
do
is
we
will
iteratively
select
each
of
these
contexts
as
current
context,
and
you
can
imagine
two
separate
stacks
and
in
each
stack.
E
That
particular
context
is
the
current
context,
because
client
only
supports
one
context
at
a
time,
so
the
user
doesn't
need
to
know
what
current
context
is.
He
just
selects
these
particular
things
and
everything
that
happens
happens
in
the
selected
context.
Yes,
that
is
the
thing
that
we
want
to
tend
towards,
but
if
that
becomes
the
default
behavior
right
now,
all
the
apis
will
break.
So
we
need
to
first
slowly
make
changes
or
any
that's
why
I
said
any
api
endpoint,
basically
anything
from
the
ui
as
well
as
messy
cd.
E
Anything
that
is
a
client
of
messily.
Anything
that
any
operation
that
has
anything
to
do
with
the
operation
on
a
cluster
on
a
community's
cluster
should
pass,
which
particular
context
it
wants
to
act
upon.
If
it
does
not
what
we
want
to
fall
back
to
the
as
of
now
at
least,
we
want
to
fall
back
to
the
default
behavior.
E
That
is
to
apply
that
on
the
current
context,
if
we
take
that
logic
out
that
okay,
there
is
no
current
context
for
now,
we'll
have
to
go
over
and
change
all
the
basically,
that
would
be
a
breaking
change
and
the
better
way
would
be
to
first
change
the
all
the
basically
to
change
the
clients
to
to
adhere
to
a
particular
kind
of
rule,
and
then
slowly
get
rid
of
that
current
context
in
general.
Dropping
the
current
context
now
would
not
be
backwards
compatible.
That's
what.
C
It
was
there
was
when
the
design
was
written.
There
was
a
request
to
either
have
a
kind
of
a
a
token
cluster
like
like
a
cluster
with
id
one,
something
like
that
that
represented
all
available
clusters
such
that
you
could
send.
You
know
someone
could
send
a
request
that
a
rather
message
server
could
receive
a
request
with
a
single
reserved
context,
identifier
that
indicated
any
available
cluster
that
mesh
re
has
is
in
communication
with
it.
Should
you
invoke
that
operation
against
them
is?
Is
there
such
a
construct?
Now?
C
The
other
aspect
of
the
initial
design
maybe
wasn't
completed
either,
and
that
was
that
maybe
it
is
so
so
on
the
what
you're
highlighting
I
think
is
that
in
the
end
points
in
golang
for
rest
anyway,
and
we
should
talk
about
graphql-
that
all
of
them
have
been
augmented
to
accept
is
essentially
one
or
more
context
identifiers
such
that
the
back
end
then
can
event
such
that
it
can
eventually
it
sounds
like
it
doesn't.
Do
it
right
now,
but
can
iterate
over
the
array
or
the
collection
of.
E
Some
end
points
too,
some
like,
for
example,
pattern
deployed
us
and
there
are
other
end
points
as
well,
which
do
this
right
now,
which
is
to
I,
if
there
is
that
query
parameter
too.
Basically,
that
query
parameter
is
extracted
at
the
middleware
middleware
level
and
put
into
that
struct
that
we
pass
around
each
handler.
So
each
handler
does
have
access
to
that
things.
C
Okay,
before
we
perpetuate
that,
that's
probably
a
place
where
we
want
to
insert
a
workflow
engine
for
how
it
is
that
I
think
it's
okay
to
have
simple
behavior
today
of
something
like
if
there's
multiple
contexts
present,
you
know
execute
across
them
in
serial
or
parallel
fashion.
Whatever
is
your
easiest
there'll
be
a
nice
there'll
be
a
nice
insertion
of
can
workflow
and
policy
there
about
that'll
allow
users
to
get
more
specific
about
kind
of
what
about
dependencies
like
what
thing
to
do
first.
C
C
C
One
other
question
is
part
of
what
you're
highlighting
right
now
is
that
for
the
apis,
these
rest
based
apis
that
don't
automatically
invoke
operations
across
every
context.
That's
specified.
It
would
be
that's
just
a
matter
of
time
before
that
happens
right.
So
there's
no
there's
no
changes
that
we're
looking
for
in
the
ui
in
measuring
server
clients,
correct.
E
Actually,
yes,
we
are
because,
because
both
machine,
ctl
and
machine
ui
right
now,
don't
necessarily
by
default,
send
what
contexts
to
act
upon
so
right
now
the
ui
does
not
send
if
I,
like
click
on
deploy
right
now,
and
this
should
actually
send
the
context
into
the
query
parameter,
and
it
does
not
do
that.
The
back
end
has
a
support
for
it
if
it
sends
that
particular
those
areas
of
context.
E
So
basically,
as
I
showed
you
when
I
clicked
on
these
things-
and
I
you
know
reloaded
the
page-
the
thing
got
overridden,
so
we
need
to
persist
these
things
when
I
click
them
from
on
the
ui
and
then
we
need
to
basically
on
each
operation
that
has
anything
to
do
with
the
cluster.
So,
for
example,
right
now,
I
selected
these
two
things
right
now.
If
I
reload
the
page,
it
doesn't
persist,
attack
it.
It
would
be
to
the
current
context
again.
E
So
if
I
selected
these
two
things,
then
even
if
I
reload
the
page,
they
should
persist
on
the
ui.
First
point
second
point:
whenever
I
invoke
an
operation,
for
example,
this
pattern
deploy
operation.
All
these
selected
contacts
should
be
passed
into
the
query
parameter.
The
back
end
has
a
support
for
it
and
all,
and
that
operation
would
be
applied
on
all
the
selected
context.
So,
yes,
the
ui
needs
some
changes
in
that
regard,
that
anything,
so
it
would
be
a
sweeping
change
across
the
way
we
call
the
endpoints.
E
E
Let's
have
a
small
question
regarding
the
behavior
when,
when
the,
when
there
is
no
selected
context
and
since
like
so
obviously,
we
can
argue
that
that
why
would
there
be
such
a
state
but
then
like?
Let's
say
that
there
is
a
state
that
the
user
is
asking
us
to
perform
a
certain
operation
and
he
hasn't
actually
provided
that.
Then
in
that
case,
I
think
we
should
actually
default
to
performing
that
operation
on
all
the
clusters
or
shouldn't
that
the
what
we
should
be
doing
or
right
now
the
default
is
to
perform
that
operation.
D
E
Okay,
I
think
in
that
case
we
should
actually
throw
some
kind
of
instead
of
you
know,
maybe
he
forgot
to
unclick
and
then
he
clicked
deploy
and
now
he
has
these
10
patents,
basically
a
one
patent
deployed
on
all
of
his
clusters
because
he
forgot.
So
I
think
this
is
more
of
a
user
mistake
that
hey
you
didn't
click
anything.
You
should
click
something
at
least
one
thing
at
least
or
if
you
want
to
select
all.
E
C
C
E
C
E
C
Makes
sense
yep,
so
it's
not
a
good
yep,
so
my
statement
still
holds
true.
It's
like
it's
totally
dysfunctional
and
we
shouldn't
like
release
it
and
expose
it
to
users,
that's
no
big
on
anyone's
effort
or
like
you're,
just
presenting
state.
You
know
point
in
time
of
like
of
the
effort
and
how
far
it
is
and
some
of
the
behaviors
around
it
and
and
it's
looking
pretty
great
like
and
it
sounds
from
your
description.
It
sounds
like
at
least
from
measuring
ui's
perspective
from
this
client's
perspective.
C
It's,
like
you,
know
this
close,
there's,
there's
only
a
a
cup.
You
know
a
handful
of
things
to
be
done.
Some
of
them
can
be.
Some
of
them
are
more
urgent
than
others,
like
one
of
them
being
some
of
them
being
more
about
convenience
like
one
of
the
issues.
Right
now
is
about
state
management
with
respect
to
like,
if
you
press,
if
you
refresh
your
ui
now
your
browser
you'll
see
a
blip
in
the
number
where
it
says
two
it'll
probably
go
to
zero
and
then
back
to
two.
C
C
C
Its
ability
to
invoke
these
operations
using
a
visual
ui
across
any
number
of
clusters,
and
actually
over
time,
have
control
over.
Maybe
you've
got
you've
got.
Maybe
we
begin
to
understand
node
groups
within
side
of
a
given
cluster.
You
might
have
many
nodes,
you
might
have
groups
of
nodes
or
node
pools.
Rather
we
might
allow
you
to
group
multiple
clusters
together
into
like
a
group
of
clusters
and
invoke
certain
operations
against
different
ones
and
things
like
it's
the
the
fundamentals
here.
C
E
Okay,
one
small
thing
that
basically
a
nitpick
in
the
ui,
basically
right
now,
as
you
can
see,
this
operator
configuration
tab
and
well
any
operator
configuration
is
specific
to
one
cluster
so
which
cluster
it
is
right
now,
so
I
have
to
click
here,
and
so
basically,
what
I'm
proposing
is
that
this
ui
should
change,
and
here
you
should
maybe
some
kind
of
I
don't
know
what
what's
that.
What's
that
called
you
know
when
you
have
like
a
stack
of
cards,
the
displays
like
that.
E
So
maybe
there's
some
kind
of
an
some
some
kind
of
tip
here
which
from
where
you
can
select,
which
particular
basically
on
what
cluster
you
want
to
see.
Your
operator
configuration
so
right
now
it
is
in
my
mini
cube.
So
if
I
so
yeah,
basically,
we
need
to
have
operator
configuration
per
cluster,
not
just
one
singular,
which
is.
E
E
Yeah,
so
my
mystery
operator
has
started
running
here
and
that-
and
it
says
on
now,
if
I
go
to
mini
cube
2
and
first
of
all
now
I
have
got
I've
gotten
to
mini
cube
too
and
still
stays
on.
If
I
reload
the
page,
then
it
says
off
and
then
basically
one
of
the
behaviors
is
that
I
think
nitish
knows
better
than
I
do
whenever
you
reload
the
settings
page.
E
We
start
the
operator
by
default.
Is
that
the
behavior
release
yeah
yeah
yeah,
so
we
need
to.
We
need
to
have
a
conversation
on
what
that
behavior
as
well.
So
when
we
want
to
start
the
operator
so
right
now
yeah,
so
the
we
now
right
now
what
you're
seeing
operator
configuration
this
is
for
mini
cube2
now,
whenever,
if
you
ping,
mesync
or
operator
or
anything
that
would
be
only
for
this
particular
thing.
E
But
it's
not
very
obvious
from
the
ui
that,
for
which
cluster
this
operator
configuration
is
being
shown
you,
maybe
you
don't
want
you
want
your
operator
here
right.
So
maybe
you
say
I
don't
want
it
here
and
if
you
go
back
now
you
don't
know
if
you
switched
it
off
for
which
context.
Now
you
basically
you
get
my
point.
My
point
is
to
have
operator
configuration
per
context
per
cluster
which
is
intuitive
to
the
user.
D
E
D
B
D
D
So
I
understand
that,
like
a
context
will
be
created
based
on
the
secret,
that's
like
in
the
in
measuring
server,
I
think,
but
I
was
thinking
that
maybe
like
disallow
the
user
from
doing
that,
maybe
like
when,
when
he
deselects
everything
like
either
all
should
be
selected
or
the
default
one
should
be
selected.
But
that's
just
my
opinion.
I
know
it's
still
working
progress,
so
maybe
that's
not
part
of
like
what
we
want
to
do.
Ultimately,
right.
D
So
there
should
be
invalid
states,
that's
what
I
mean
like
if
some,
if
something
is
invalid,
we
shouldn't
allow
a
ui
user
to
to
to
leave
that
inconsistent
state,
because
that
then
we
would
need
to
handle
that
scenario
in
every
place.
You
know
in
different
handlers
and
different
processes,
and
I
think
it's
just
a.
A
A
E
C
C
Well
that
really
determines
what
you're
what
you
should
be
seeing
like
for
every
single
screen,
there's
different
approaches
to
how
this
can
be
done.
You
can
the
approach
that
we're
taking,
at
least
in
the
ux
that
we
have
is
that
this
is
so
central
to
your
operational
procedures,
by
which
you're
you
know
using
kubernetes,
by
which
you're
using
a
service
mesh
by
which
you're
running
your
workloads
is
well.
C
So
if
we
take
a
step
back-
and
we
say
you
might
have
started
using
a
container-
and
you
got
yourself
a
bunch
of
containers
at
one
point-
you
started
doing
some
serious
things.
You
found
the
need
for
a
container
orchestrator,
so
you
grabbed
some
some
kubernetes.
You
grabbed
the
kubernetes,
eventually
you're
doing
enough.
Well,
you
need
your
production
kubernetes,
your
qa,
your
development.
C
You
need
the
one
over
in
europe
and
down
in
south
africa
and
the
one
over
in
the
us
to
be
multi-region
and
failover
and
then
across
multi-cloud,
and
then
along
comes
one
of
your
teammates
or
the
rest
of
your
team.
Mario's
organization
comes
in
they're
disruptive.
They
want
to
do
some
things,
so
you
want
to
give
them
some
different
clusters.
C
C
Oh
wow
wait
a
second.
How
many
cluster
you
know
like
so
the
my
point
of
going
through
all
that
is
to
say
that
this
is,
you
know,
front
and
center.
This
is
why
you
need
a
higher
level
capability,
like
mesh
re,
like
a
management
plane
to
to
help
you
it's
not
just
a
control
plane,
not
just
control
of
just
so
the
approach
that
we're
taking
it
yeah.
It
needs
to
do
what
augusta
had
hinted
as
well
as
what
mario
was
saying.
Mario
was
saying:
hey.
C
We
should
probably
embrace
the
principle
of
don't
don't
let
people
shoot
themselves
in
the
foot.
Don't
let
users
shoot
themselves
in
the
foot
if
you
can
like
surprise,
never
really
a
pleasant
experience?
Yes,
should
they
or
no,
they
shouldn't
be
trying
to
execute
an
operation
against
zero
clusters?
That's
probably
not
going
to
work!
Well,
it
might
there's
some
things
they
can
do.
It
doesn't
require
a
cluster,
but
if
it
requires
a
cluster,
why
would
we
let
them
do
that
that
hurts
don't
let
them
do
that,
provide
them
with
a
pleasant
experience.
C
That
design
principle
to
me
makes
tons
of
sense.
There
are
some
cases
where
you
do
desire
to
allow
users
to
situate
themselves
such
that
they
they
can
take
the
gun
out
of
their
holster,
like
talk
back
to
the
hammer
and
like
just
before,
they
pull
the
trigger
you,
you
stop
it
and
so
an
example
of
something
like
that
is
if
I'll
use,
mario
as
an
example.
C
Again,
if
he's,
if
he's
got
a
pattern,
the
pattern
has
an
envoy
filter
in
it
and,
as
it
turns
out,
the
meshri
system
that
he's
running
maybe
doesn't
have
that
filter
loaded.
So
is
it
valid
for
him
to
be
in
a
situation
in
which
he's
got
his
gun
out,
he's
got
his
hammer
back.
He's
got
this
pattern
that
describes
the
fact
that
it's
going
to
use
a
filter,
that's
actually
not
present.
So
just
before
he
clicks
the
deploy
button.
C
Maybe
he
can't
pull
the
trigger
and
click
deploy,
because
it's
just
going
to
fail
like
that
filter
isn't
present,
so
so
there's
a
the
you
can
let
them
get
close
to
you
can
let
them
work
up
to
the
point
that
they
pull
the
trigger?
I
guess
is
what
I'm
trying
to
point
out,
and
some
of
those
concepts
are
already
built
into
some
of
you
have
built
those
concepts
into
mesry
already
exactly
what
I
just
described,
actually
there's
a
very
validation
process
that
happens
for
patterns
to
figure
out.
C
So
you've
got
this
global
navbar
readily
handy
switcher
between
these
contexts,
because
you're,
essentially
looking
at
anything
in
this
client
in
mastery
ui
anything
that
you're
seeing
you're,
essentially
seeing
it
through
right
now,
anyway,
through
the
lens
of
what
you
have
selected.
If
you
have
two
clusters
selected,
then
you
should
see
all
the
info
samurai.
C
You
know
if
you're
looking
at
a
dashboard
report
or
something
you
should
see
all
that
info
for
all
of
them
and
that
you
know
design
cons,
and
so
when
we
need
to
go
back
and
review
each
screen
like
the
measuring
operators,
the
system
settings
screen,
we
don't
we
don't.
We
can
either
refactor
or
potentially
start
fresh
in
terms
of
how
it
is
that
you're
managing
what
cluster
you're
trying
to
manage
and
whether
or
not
that
cluster
has
an
operator
and
whether
or
not
that
operator
is
healthy.
C
C
C
Ultimately,
there's
a
spec
that
navindu
and
I
had
given
some
thought
to
some
time
ago
about
mastery
cto
and
what
does
it
mean
for
the
other?
Meschery
client,
not
just
measure
ui,
but
mastery
ctl
to
potentially
be
cognizant
of
the
fact
that
there's
multiple
kubernetes
clusters
that
are
in
your
environment
and
you
might
want
to
be
provisioning
against
them
or
interacting
against
them.
C
You
know
I
didn't
mean
to
harangue
everyone,
but
it's
just
there's
a
lot
to
this
and
it
becomes
you
you'll
eventually
find
when
this
is
done.
Well,
there'll
be
some
users
that
are
pretty
tickled
by
the
power
of
what
they
can
accomplish
across
these
clusters
across
their
service
meshes
across
their
applications,
with
just
a
click.
C
So
to
mario's
point
again:
gosh
if
it's
just
a
click
and
you
can
affect
that
much
infrastructure.
Maybe
we
shouldn't
let
you
pull
the
trigger
unless
it's
going
to
work
so
which
again
brings
up
my
point
about
a
workflow
engine,
the
ability
to
insert
like
approvals.
Actually,
as
you
go,
to
invoke
an
operation.
Should
it
be
the
case
that
that
lee
should
have
the
pattern
or
the
the
button
that
deletes
clusters
that
doesn't
sound
like
a
good
idea
to
mp.
We
should
probably
stop
leave
from
doing
that,
or
at
least
have
someone
else
review.
C
So
so,
if
you're
unfamiliar
or
something
many
of
you
are,
but
if
you're
unfamiliar
kind
of
the
big
milestones
between
the
the
current
version
of
mastery
that
we
already
have
today
and
the
dot
the
1.0,
it's
got
two
large
architectural
components.
A
workflow
engine
approvals
can
be
inserted
into
any
workflow
step.
That's
a
good
example
of
what
you'd
use
a
workflow
engine
for
you
use
it
for
many
other
things
and
a
policy
engine.
C
Policies
for
all
kinds
of
things,
I
think
people
often
think
about
authorization,
policies,
permissions
and
things,
but
there's
a
lot
of
different
types
of
policies
you
might
want
to
and
enforce,
and
if
you're
confused
as
to,
why
do
you
need
both
a
policy
engine
and
a
workflow
engine
to
help
reinforce
help
clarify
that
a
little
bit
your
policy
engine?
You
really
want
to
be
able
to
express
you
want
to
be
able
to.
You
want
an
expressive
language
in
which
you
can
describe
a
particular
desirable
thing,
a
particular
policy,
and
then
you
want
a
ver.
C
Well,
ideally,
a
distributed
highly
inter
integrated
engine
that
does
eval
it's
an
evaluation
engine.
It
takes
your
expressive
policy
and
it
says
of
the
things
that
you've
described.
Is
that
true
or
is
that
false
or
you
know
what
what
like
evaluate
this
eva
well
evaluated
in
the
distributed
nature,
understanding
that
a
lot
of
the
things
you
might
describe
in
that
policy
might
be
distributed
themselves,
so
that's
a
whole
challenge
under
its
own,
so
hence
a
policy
engine.
Now
when
the
policy
passes
or
doesn't
pass,
what
should
you
do
about
it?
A
Okay,
I
guess
not
so
moving
on,
we
yeah,
we
participate
in
a
number
of
programs
and
our
recent
two
recent
programs
that
we
are
going
to
participate
in
is
open
force
and
she
called
africa.
So
there
are
I've
listed
on
a
couple
of
things
that
we
need
to
look
into
right
now,
as
of
now.
So
only
do
you
have
any
other
updates
apart
from
this,
so
one
thing
is:
we
have
to
add
this
over
here
on
our
program
switch.
A
We
have.
We
also
have
to
add
a
post
for
the
event
over
here
and
what
I
was
thinking
is
the
write-up
which
you
had
that
could
be
modified
and
added
as
a
description
in
that
ship
right.
I
wrote
few
days
ago,
I
guess,
and
that
could
be
used
as
spell
for
this
to
discount
it
and
they
win
stuff,
maybe
also
like
we
have
mentors,
are
selected
for
open,
open
force.
A
One
is
abhijit,
he
is
here
nikhil
and
my
dad,
so
these
three
people
would
be
there
at
open
force,
guiding
people
regarding
layer,
5,
open
source
projects.
Also,
we
need
to
select
certain
projects
that
would
be
taking
part
in
open
force.
Maybe
certain
repositories
under
mystery
or,
and
we
have
to
look
for
the
open
issues
as
well.
So
if
anyone
is
interested
to
volunteer
for
the
same,
I
like
I
can
share
the
talk
and
you
can
get
started
with
it.
So
yeah.
C
D
C
A
C
Awesome
and
then
so
you're
tracking
a
list
of
mentors
as
well,
good
and-
and
it
sounds
like
I
suspect
you
still
have
kind
of
an
open
call
out
not
only
for
those
that
might
want
to
participate
as
a
mentor.
But
but
you
also
have,
I
suspect,
a
call
out
for
just
sort
of
refining
preparing
areas
of
potential
participation,
kind
of
refining
some
issues
or
mini
projects
that
participants
might
work
on
chew
on
you
know
over
the
month
or
so
that
their
open
force
is
going
on.
C
Unati
and
and
others
can
help
point
out
where
to
engage
unani.
It's
one
of
the
things
that
to
to
assist
there
you
it
would
be
appropriate
to
suggest
to
each
of
those
that
have
volunteered
to
mentor
that
they
themselves
give
consideration
as
to
where
they
think
they
could
help
someone,
or
you
know
like
what
what
what
aspect
of
one
of
the
projects
they
might
be
able
to.
A
C
A
C
A
Okay,
so
for
the
open
issues,
we'll
probably
have
to
go.
Do
a
bug
hunt
on
most
of
our
projects
find
out
everything
that
needs
to
be
fixed
and
start
creating
issues
for
that
we
can
probably
track
them
or,
I
think,
make
those
labels
tag
for
the
issues
with
open
force
so
that
we
can
guide
people
to
that.
C
Okay,
although
yes,
although
I
will
say
this
that
like
if
we
end
up,
do
creating
a
an
issue
label
and
we
actually
propagated
across
the
70
repos
that
we
have
great,
but
if
and
then,
but
if
someone
comes
along
and
wants
to
work
on
the
issue
like
it
doesn't,
and
you
say
well,
are
you
participating
in
open
force?
No
okay?
Well
then,
no,
you
can't
work
on.
It's
like
well,
like
that's,
not
really
how
we
want
it
to
work
because
a
that
doesn't
feel
good
b.
C
B
Hi
everyone
so
on
super
africa.
There
is
do
nothing
yet
as
of
now,
because
we
are
still
waiting
for
could
have
got
to
get
the
mentees
ready,
they've
not
really
picked
mentees
yet,
but
then
chatting
up
with
right.
Now
to
so
we
can.
We
can
sign
up
layer
5
as
a
participating
organization,
so
we
start
from
there.
B
B
C
B
C
So
there
there's
some
there's
some
progress,
some
momentum,
so
just
for
everyone,
that's
kind
of
involved
in
between
chico
africa
and
open
force.
It's
worth
noting
that
chico
africa
and
bombi
correct
me.
If
I
mischaracterize
this,
but
at
least
as
it
ran
last
year,
was
that
the
individual
participants
are
named
if
you
will,
or
rather
there's
a
kind
of
a
qualification
process
or
a
selection
process
and
and
in
sort
of
a
pairing.
B
So
yeah,
yes,
there
was
the
selection
process,
because
the
criteria
for
participating
in
contribution
is
that
the
person
should
be
someone
that
is
used
to
the
used
to
open
source
you're
already
like
contributing
to
open
source,
and
you
have
knowledge
of
this
particular
project.
You
want
to
contribute
to
also
so
those
are
the
criteria
for
contributing.