►
Description
Dan Romlein, Google
Jeff Sica, University of Michigan
This session is to plan out the future efforts of SIG-UI. If you're not a SIG-UI participant, we'd still love to hear your opinions and feedback! We will discuss Q1/2 2019 projects, the infamous Angular migration, and feedback received from users.
A
So,
hey
everyone,
I'm
Dan
ROM
line
I'm,
one
of
the
co
leads
of
CQI
I'm,
a
UX
experienced
user
experience
designer
at
Google
and
I've
been
involved
in
the
open
source
kubernetes
project
for
about
two
years
now,
primarily
operating
in
situ.
I
working
on
dashboard
that
provides
some
pretty
good
context.
Hopefully.
B
E
F
C
F
G
D
D
D
So
we
had
a
lot
of
responses.
K-Member
area
now
I've
taught
my
head
like
a
hundred
and
ninety
or
something
yeah,
so
eight
hundred
eighty,
so
responses
from
sort
of
people
of
all
different
backgrounds,
and
we
have
some
questions
looking
into
their
experience
using
kubernetes
that
they're
how
much
knowledge
they
had.
Oh.
D
D
So
if
we
go
down
to
some
of
these
questions,
that
I
think
kind
of
talk
to
you,
some
functionality,
that's
missing,
so
being
able
to
see
resources
from
multiple
clusters
showed
up
as
being
very
important,
both
here
just
in
general
and
then
also
further
down,
or
we
asked
what
we
call
that
specific
features
to
see
how
important
those
were.
So
you
can
see
that
I'm
definitely
feature
parity
with
cube.
D
D
F
D
D
Yeah
and
then
security
came
up
again
as
a
concern.
People
have,
you
know,
I'm
sure,
that's
nothing
new
here,
but
some
of
those
things
that
were
mentioned
kind
of
that
I
at
least
categorized
as
security,
where
I
think
also
new
functionality,
basically
like
the
more
and
this
might
just
be
also
covered
on
integration,
but
the
more
the
easier
it
is
for
people
to
manage.
Logins
and
access
controls,
the
more
kinds
of
people
that
will
be
able
to
use
dashboard.
So.
D
D
And
the
other
other
interesting
things,
so
we
have
some
questions
around
using
dashboard
for
learning,
kubernetes
versus
monitoring
and
managing
and
just
looking
kind
of
like
eyeballing
the
averages
here.
You
can
see
a
lot
of
people
rated
it
useful
for
learning
and
then
that
kind
of
dropped,
as
you
got
down
to
monitoring
and
then
sort
of
I
think
became
even
lower
for
managing
so
I.
D
Think
yet
there's
definitely
this
interest
in
using
dashboard
as
a
way
to
sort
of
onboard
on
to
kubernetes
and
also
a
sort
of
a
read-only
view
of
your
resources
and
then
I
don't
know
if
this
is
the
best
practice,
but
I
think
there's
some
understand
like
right.
Making
changes,
maybe
in
UI,
maybe
isn't
the
best
way
to
do
it.
D
A
G
G
G
G
So
if
you're
on
open
sacra
free
on
AWS
or
you're
on
GCP,
you
have
a
storage
driver
that
is,
they
like
manage
it
for
that
cloud
provider
and
they're,
spinning
out
a
lot
of
the
cloud
specific
stuff
from
the
main
repo
and
making
integrations
form
and
I'm
almost
wondering
if,
with
these
integrations,
we
could
do
something
similar
on
top
of
things
like
we
need
to
integrate
with
prometheus
and
have
better
off,
etc,
etc.
I
think.
G
Being
able
to
point
dashboard
at
Prometheus
or
cloud
watch
or
I
can't
remember
all
the
different,
like
metrics
providers
for
the
cloud
providers
so
that
you're
hitting
that
one
place
for
your
historical
data.
So
maybe,
if
you're
in
gke,
you
don't
need
to
run
Prometheus
because
everything
is
in
I
forget
the
Google
product.
But
then
you
can
point
dashboard
at
that
and
that's
where
you're
getting
your
metrics
stackdriver
stackdriver.
Thank
you
so
that
that
kind
of
integration
metric
metrics
is,
you
know
hot
in
my
mind,
right
now,
because
of
what
I've
been
doing.
G
But
you
know
it's
also
a
good
example
of
integration.
Ya
see
RDS
was
another
big
one
being
able
to
and
that
kind
of
make
sense
being
able
to
just
show
CRTs
within
dashboard,
as
well
as
maybe
have
a
better
way
to
manage.
Cr
DS
in
the
dashboard
I
think
step.
One
is
just
being
able
to
view
them
because
we
can't
now
we're
just
kind
of
going
through
this.
F
A
G
F
E
G
So
we
do
this
front-end
test
whenever
there's
a
nuke
pull
request
and
it
goes
through
sauce
labs
and
that's
why
a
lot
of
your
PRS
will
be
flaking
and
say
that
they
won't
work
even
though
they're
fine,
multiple
times
I'm
just
going
and
hitting
restart,
build
and
hoping
it
works.
We
no
longer
need
that
because
of
all
the
testing
in
angular
2.
G
He
said
that
scraping
the
metrics
server
is
frowned
upon
and
should
not
be
a
long-term
solution,
so
it'll
probably
be
a
stopgap
until
we
start
building
these
better
integrations
and
we
can
point
to
something
like
Prometheus
or
I
already
forgot
stack
driver.
Thank
you.
So
once
we
finalize
that
and
push
that
live
will
at
least
be
able
to
support
metric
server,
which
is
a
separate
discussion
we
have
to
make,
because
we
need
to
make
it
an
official
container,
which
means
we
need
a
separate
repo
under
kubernetes
SIG's.
G
So
that
is
something
we
need
to
action
item
and
figure
out
after
the
conference.
So
those
are
really
the
two
big
things
there
is
the
security
PR
that
is
hopefully
going
to
get
resolved.
I
know
that
Sebastian
asked
Jordan
Leggett
to
look
at
it
like
several
hours
ago
yep
and
it
was
a
minor
fix.
Otherwise
that
is
probably
going
to
trigger
a
new
release
in
like
the
next
week
sooner.
The
better.
G
We
had
the
the
issue
where
you
could
press
skip
login
and
then
you
could
just
log
into
the
dashboard
and
that's
not
too
terrible,
except
then
you
can
see
all
the
cube
system
secrets.
So
that's
problem.
They
fixed
it
briefly
by
pushing
they
just
disabled
to
skip
login
button,
but
we
never
cut
a
release
after
that.
So
it
was
just.
G
It
was
in
master
and
that's
fine,
but
it
wasn't
so
we
should
have
cut
a
release
sooner,
but
the
other
thing
was:
the
kubernetes
security
team
suggested
a
much
more
comprehensive
fix,
rather
than
let's
just
remove
the
button.
So
they
have
this
much
more
comprehensive
fix
and
we're
just
waiting
for
feedback
from
them
and
then
pretty
much
at
this
point.
G
Even
if
the
metric
stuff
is
not
solidified,
we
should
cut
a
new
release
just
to
get
this
done
and
not
worry
about
it
and
at
that
point
I
think
we
can
just
wait
for
the
metric
stuff
until
the
angular
2
migration
and
then
we'll
just
roll
it
up
and
do
a
much
bigger
like
version
112
or
111
I
think
yeah.
So
it
again
once
this
is
done,
we
should
just
cut
a
release.
Have
it
be
a
security
hot
fix
and
be
like
we're
on
110,
1,
I
or
110
I?
Forget?
G
G
G
B
It
seems
like
it
makes
sense
as
we
released
the
ng
2
migration
at
whatever
state
were
in.
If
113
is
the
active
kubernetes
release,
then
that
release
would
kind
of
skip
over
the
111
and
112.
We
update
the
go
Deb's,
and
so
the
actual
go
version
in
dashboard
is
also
imperative.
With
that
that
seems
to
make
the
most
sense.
I
know
that
things
have
kind
of
lulled
and
gone.
You
know
kind
of
push
and
pull
there.
G
F
G
A
E
A
G
So
I
think
this
kind
of
goes
back
to
the
ability
of
doing
integration
so
like
you're,
looking
to
integrate
dashboard
with
Lucy's
product.
Tell
me
if
I'm
pronouncing
that
right
by
the
way,
okay
and
a
lot
of
people
want
integrations
with
their
metric
pipelines
or
those
see
ICD
pipelines,
and
if
we
provide
a
decent
path
to
both
build.
Those
integrations
as
well
as
give
some
example
integrations
that
opens
the
door
for
a
lot
more
contributors
to
build
stuff
for
their
own
thing
that
they
can
kind
of
put
into
the
dashboard.
G
So
I
think
that's
one
good
way
to
get
contributors
going.
Another
thing
is
a
lot
of
people
have
concerns
about
the
security
of
the
dashboard,
and
that
is
something
that
we
need
to
address
almost
immediately
besides,
the
CVE
fix
so
having-
and
this
is
also
in
the
slides
and
the
the
data
as
well
having
better
o
auth
support,
having
a
better
means
of
logging
in
I,
think
that
will
drive
more
adoption
to
the
dashboard,
which
will
then
have
more
users
that
want
to
build
things
in
the
dashboard.
D
Yeah
that
bit
about
supporting
off
and
other
ways,
login
definitely
came
out
in
the
research
as
something
that
was
super
useful
for
people
or
would
be
super
useful
people.
And
there
are
a
lot
of
people.
A
lot
of
people
have
stakeholders
that
are
not
able
to
use
the
dashboard
for
various
reasons
right
now,
including
security
and
people
who
they
don't
necessarily
want
to
allow
to
change
anything
or
even
view
too
much
but
they're,
just
like
certain
things
that
they
want
their
managers
or
executives
to
be
able
to
see
and
being
able
support.
E
E
How
do
I
log
in
now
into
the
dashboard,
because
at
a
certain
time
it
stopped
working
and
so
I
was
what
do
I
need
now,
especially
when
I
run
it
on
uke,
because
there
is
no.
Even
if
you
use
the
cube
config,
you
upload
the
cube
config
and
then
it's
like
still
not
working
strange
and
it
says
yeah
use
your
cube,
config
and
so
I
really
start
digging
deeper
into
it,
to
figuring
out,
okay
and
or
looking
into
the
documentation
with
somewhere.
E
It
says:
okay,
you
can
create
a
service
account
uses
token
and
all
the
stuff,
but
I
think
we
must
yeah
fix
this.
That's
the
one
side,
it's
much
better
user
experience
and
that
from
the
security
perspective,
you
really
only
allow
what
your
user.
It's
also
a
lot
to
see
and
not
like
okay,
my
user
somehow
limited.
But
now
it's
a
token
I'm
Superman
again.
G
So
one
of
the
one
of
the
things
that
I
think
would
be
good
is
a.
We
focus
on
being
able
to
do
OAuth
better,
so
you
can
just
point
it
at
a
good
OAuth
end
point,
but
then
there's
the
matter
of
great
you
can
authenticate,
but
they
aren't
authorized
to
do
anything.
So
the
next
thing
would
be
once
we
have
the
workflow
for
just
logging
in
solved
and
in
a
better
state.
G
We
then
focus
on
a
way
for
a
cluster
admin
or
someone
that
has
rights
to
then
be
able
to
easily
from
the
dashboard
grant
our
back
rolls
and
rights
to
OAuth
users
now
right
now.
The
way
that
we
do,
that
is
using
keek.
Well,
this
isn't
for
dashboard,
but
for
like
cube
cuddle.
The
way
that
we
do,
that
is
using
key
cloak
to
map
to
different
key
cloak,
becomes
an
OAuth
provider
that
maps
to
local
resources.
G
That's
really
that's
a
phat
solution
for
us
I'm,
mainly
thinking
like
if
they
want
to
point
to
Google
or
github,
for
their
o
auth
provider
being
able
to
then
just
map.
You
know,
chief
1,
1,
1
X
at
gmail.com.
Has
this
our
back
role
in
the
cluster
if
we
can
solve
the
OAuth
and
then
solve
that
mapping
in
a
fairly
lightweight
way,
I
think
we
solve
like
98
percent
of
people's
OAuth
problems,
because
I,
don't
think
they're
I,
don't
think
and
correct
me
if
anyone
has
data.
G
This
is
entirely
like
just
based
on
what
I've
talked
to
people
about
people
aren't
trying
to
run
their
own
off
providers
on
top
of
kubernetes
they're,
usually
pointing
to
something
like
a
github
org
or
a
like
Google
org,
and
that
is
who,
like
that
is
their
main
ooofff
provider
they're
not
dealing
with
like
a
local
LDAP
account
or
Kerberos.
God
help
us
all.
You
know.
E
Yes,
it's
also
the
experience
we
we
do
it
with
Cuba
metric
I
mean
what
we
do
there.
It's
like
we're
using
decks
as
a
proxy.
Only
and
then
I
mean
especially
like
in
the
enterprise.
Everyone
has
like
an
source
of
like
either
they
have
added
up,
or
they
have
an
or
provider
there
and
as
I
don't
want
to
set
up
a
new
provider.
E
Also
from
security
perspective
like
as
I
want
to
have
such
a
single
button,
this
a
versus
user
and
then
it
should
be
automatically
disabled
in
all
the
system
and
not
like
oh
yeah,
there's
a
kubernetes
dashboard.
We
have
another
users,
AI
must
maintain
manually,
I,
think
somehow
we
need
something
like
a
proxy
like
Tex
or
I.
Think
50
cloaks
this
also
now
available,
and
then
we
can
like,
as
an
example,
implementation
say,
also
hey.
E
You
can
set
up
key
cloade
separately
as
you
user
management
as
a
reference
and
then
reference
also
to
like
other
options,
our
github
Google,
and
what
the
hell
and
then
yeah.
You
can
connect
this,
and
then
it
should
map
to
the
same
authorization.
You
have
inside
the
classes
that
you
yeah
the
API
service
using
so
that
you
end
up
with
the
same
authorization.
E
B
I
would
agree
with
that
point:
I,
think
a
lot
of
enterprises
are
using
LDAP
or
Active
Directory
and
want
to
integrate
that
I
do
agree,
there's
a
lot
of
like
other
companies
going
for
Google
or
you
know,
github
I,
don't
think
you're
incorrect
in
that
statement,
we're
personally
looking
at
or
we
are
using
text
for
Oh
IDC
provider
right
now.
The
issue
that
I've
seen
with
it
too.
You
talked
about
you
disable
user.
B
Now
that
they're
disabled
permanently
I'm,
pretty
sure
I'm,
not
who
wouldn't
bet
my
first
board
on
it,
but
I'm
pretty
sure
that
Dex
right
now
uses
custom
resource
definitions
to
store
those
tokens,
and
so
once
you
validate
once
you
validate
your
LDAP
and
that
stores
the
token
and
a
CR
D,
and
so
then,
even
if
you
disable
them
in
LDAP,
it
doesn't
fix
that
whole
lifecycle
of
disabling
an
LDAP
and
now
they're
disabled
in
there.
That's
another
topic
for
another
day,
but
I
completely
agree
at
we're.
B
Seeing
this
problem
too,
using
those
authentication
providers
there
and
based
on
what
we
saw
with
the
slides
and
the
the
talkin
Shanghai.
Was
that
there's
a
lot
of
questions
around
our
back?
You
know
today,
when
you
install
the
dashboard,
we
say,
create
an
admin
user
grab
the
token
throw
it
in
there
and
you're
good,
and
the
problem
with
that
is
is
what
next
now,
what
if
I
want
to
use
our
limited
to
a
namespace
or
something
like
that?
B
One
thing:
I
wanted
to
focus
on
some
of
the
documentation
that
story
of
how
you
install
the
dashboard
and
improving
some
of
the
are
back
at
least
examples.
Here's
an
example,
our
backup,
some
unlimited
to
read
only
to
a
certain
namespace
and
people
can
take
these
example.
Cookie
cutter
are
back
and
then
apply
them
to
their
cluster.
If.
B
Well-
and
the
second
part
of
that
too,
is
the
queue
configure
issue
and
I
ran
into
that
personally.
I
saw
oh
I,
need
my
queue,
config
same
problem,
upload
it
and
find
out
that
it's
not
for
an
x.509.
It
wants
a
token
and
I'm
guessing
that's
due
to
the
API
right.
Api
wants
that
bearer
token,
but
you
can
use
a
cube
config
if
you
have
your
bear
token
as
part
of
your
cube
config.
So
it's
a
little
confusing
yeah.
E
As
a
cube,
config
like
when
you're
using
the
default
cube
config
from
from
Google,
it
has
a
provider
in
it,
and
so
it's
not
working
at
all
because
as
I'm
talking
and
when
you
have
a
cube
config
with
a
token
it's
working
without
a
problem.
But
it's
not
really
obvious
that
you
need
a
cube
conflict
with
a
token
and
that
not
every
cube
config
is
provided
or
supported.
The
question
is
potentially
what
we
also
should
talk
with
us.
E
Otherwise
we
must
set
up
another
one,
and
then
it
can
be
tricky
where,
like
like
on
the
Google
side,
you
would
on
the
gke.
You
would
use
this
you
with
Google
logins
for
this
and
then
the
setting
up
someone
else
with
github,
but
then
it's
already
again
not
matching.
If
we
can
somehow
go
from
the
communities
dashboard
to
the
Cubans
API
so
and
somehow
get
a
valid
chain.
E
Working
I
haven't
looked
into
it,
but
when
we
get
this
somehow
working,
it
would
be
easy
because
then
we
don't
nothing
at
all
into
how
we
establish
the
or
chain,
because
the
Cuban
ities,
API
server
is
already
doing
this.
And
then
you
can
be
sure
the
user
who
is
available
on
the
API
service
is.
You
can
use
the
same
on
the
dashboard,
because
otherwise
you
can
already
set
it
up.
That's
not
mapping
and
then
I
think
you
can
run
into
problems
or
in
confusion
with
customers,
and
they
say,
as
you
cannot
see
something
I
used.
B
And
one
last
thing,
I
agree
to
those
points
is
definitely
is
that
confusing
user
story
when
you're
coming
on
board
and
what
you
can
see
you
there
just
a
crazy
idea,
throwing
it
out
there
spitballing
is
what
if
there
was
some.
Let's
assume
that
the
efforts
were
done
to
create
some
sort
of
authentication
mechanism,
so
you
can
use
github,
you
can
use
LDAP
Active
Directory.
Whatever
sort
is
done
there
I
think
our
Beck
is
one
of
those
things
that
could
be
a
gray
area
depending
on
your
experience
level
with
kubernetes.
It
can
be.
B
The
spitballing
idea
would
be
what,
if,
when
you
log
in
with
no
authentication
period,
the
first
page
you
get
is:
let's
generate
an
hour
back
basically
dropped
in
as
I
want
to
see
view
create,
git
or
some
form
of
plain
English,
of
what
you'd
want
and
in
our
Beck
file.
It
would
then
generate
that
file
or
whatever
I,
don't
know
the
next
step
of
how
it
would
generate.
B
Then
it
would
give
you
the
cube,
CTL
or
cube
Caudill
command
to
create
that
our
back
rule
for
that
user,
you're
authenticated
as
assuming
you'd,
have
a
cube
cuddle.
That's
admin
because
you're
creating
your
cluster,
so
you
login,
you
have
no
permissions
whatsoever.
It's
a
blank
page!
Hey!
You
need
our
back.
You
have
no
our
back
period.
We
let
you
through,
because
you're
just
nobody.
F
A
G
I
think
we
should
look
at
it
as
assume
angular,
migration
and
metrics
are
done
by
the
end
of
the
year.
We
might
not
have
a
release,
but
you
know
start
2019
fresh.
What
things
do
we
want
to
try
and
focus
on
in
2019
and
at
that
point,
maybe
after
this
we
kind
of
figure
out
what's
feasible,
priority,
etc,
etc.
Yeah
and
the
thing
that
we
have
heard
an
abundance
of
is
integration.
G
B
Know
I
think
I
can
speak
of
that
because
I'm
interested
in
all
that
cluster.
Personally,
it's
individual
clusters
not
using
Federation,
not
Federation,
v2
I,
just
have
cluster
sprawl
and
I,
want
one
pane
of
glass
or,
at
the
very
least,
to
be
able
to
see
a
list
of
all
my
resources
jump
into
another
dashboard
from
that
single
pane.
E
Yeah
I
see
this
also
because
we
discussed
this
also
internally,
but
I
think
this
also
has
quite
some
challenges
because,
like
currently
you
can
solve
and
so
on,
all
on
the
indigo
client,
if
you
do
multi
class
that
we
first
must
think
about
a
concept.
Okay,
if
I
want
to
have
the
top
ten
entries
of
three
clusters,
where
do
we
sought?
E
Do
we
have
like
in
the
middle
or
do
is
copy
the
data
first
into
a
separate
EDD
that
we
kept
proper
sort
or
especially
when
we
have
a
lot
of
entries
things
like
this,
and
you
don't
want
do
it
if
one
saw
spot
in
each
cluster,
we
don't
want
to
scribe
every
cluster
first
and
then
like
putting
it
up,
sorting
it
and
then
putting
out
ten
ten
data,
or
so,
from
my
perspective
like
important
from
our
side.
It's
like
security
and
integration
and
I,
saying
like
for
from
widget
lesser.
E
We
should
be
like
potentially
invest
integrate.
How
to
do
this,
but
I
think
there
are
a
lot
of
questions
would
first,
must
be
really
discussed
and
figure
out.
What
really
must
first
really
understand.
Okay,
what
are
the
questions
from
the
end
user
words
I
want
to
achieve
and
what
other
than
the
technical
implications,
because
we
had
this
discussion
and
we
came
immediately
with
a
lot
of
points
with
it:
okay,
yeah,
it
sounds
an
interesting
idea,
but
how
should
we
implement
this
in
in
detail.
E
B
Yeah
I
think
integration
is
more
important
long
term
for
the
usage
of
dashboard
contributor
adoption,
but
I
think
I
think
that
that
story
there
of
getting
dashboard
authentication
token,
is
really
messy
today
and
I
think
that
the
barrier
to
entry
is
a
little
higher
for
a
novice
starting
out
in
kubernetes
and
I.
Think
that
if
we
don't
fix
it
at
least
explain
what
you
can
and
cannot
do
more
clearly
than
just
saying
here,
we'll
take
a
cube,
config
file
and
take
a
toke
and
make
it
more
clear.
What
exactly
we
need.
B
G
Would
agree,
I'm
also
wondering,
if
it's
possible
for
us
to
make
integration
like
our
top
priority
and
make
it
so
all-encompassing
that
authentication
is
another
integration,
so
eventually
we
could
do
something
like
LDAP
as
a
first-class
citizen.
As
far
as
dashboard
authentication
goes
now,
there's
a
challenge
that
immediately
comes
to
mind
there,
which
is
we're
probably
gonna,
have
to
have
some
sort
of
like
datastore.
In
the
background
that
we'll
be
able
to
map
this
LDAP
user
has
this
are
back
profile,
but
that's
not
that's,
not
a
hard
problem
to
solve.
E
But
why
do
we
need
this
tall?
Why
do
we
need
to
start
to
like
I
mean
Kuban?
Is
itself
also
don't
need
the
store,
I.
Think
I
would
first
look
into
more
like
how
we
can
rely
on
the
authorization
communities
as
and
not
building
another
layer
of
complexity
into
the
dashboard.
For
me,
the
dashboard
is
only
like
viewing
the
entries
you
can
get
from
cube,
City
a
a
an
easy
way
to
do
cube
CTA,
and
so
it
should
exactly
work
in
the
same
way.
E
B
Going
along
the
line,
I
totally
agree
to
you
know.
So
if
someone
was
using
Dex,
then
their
API
server
is
looking
at
the
X
as
their
o
ID
C
provider.
When
you
go
to
login,
you
have
to
have
a
client
apps
trying
to
talk
about
the
the
life
cycle
here.
I,
don't
know
where
that
all
fits
in,
but
it'd
be
awesome.
If
that
you
know
dashboard,
logon
was
username
password
that
could
then
fall
into
decks
or
whatever
your
ID
C
provider
is
same
if
it
was
Google
or
something
you
entering
your
Google,
username
and
password.
B
H
So
from
like
an
admin
point
of
view,
but
what
our
company's
does
kind
of
like
its
standard
Kuban,
it
is
nothing
super
crazy
but
like
again,
there's
a
bunch
of
developers
and
we
don't
want
to
give
sorry-
we
actually
want
those
developers
to
actually
be
able
to
use
the
dashboard
of
course.
So
the
thing
for
us,
the
number
one
problem
is
the
integration
and
the
authentication
thing
right
now.
What
we
do
is
okay
run
this
command.
H
We
refresh
your
cube
CTL
token
and
then
grab
that
token
and
then
paste
it
here,
but
that
token
expires
every
one
one
hour
of,
of
course,
so
that
it's
kind
of
like
you
have
to
do
this
over
and
over
again
and
everything
right.
So
for
us,
integration
into
the
API
servers
authentication
mechanism
is
I
to
me
is
number
one
priority
for
for
for
for
solving
that
plus,
like
I,
don't
know
whether
you
guys
discussed
this
before
sorry,
I
came
and
made,
but
like
to
me
like.
H
Resources
see
logs
and
everything
but
like
as
an
admin
can
take
away
your
edit
permissions
or
whatever
for
the
for
the
day
for
the
dashboard,
because,
like
we
want
to
keep
doing
the
decorative
style
and
I
think
and
then
nothing
thanks
to
you,
I
and
not
seeing
secrets
through
the
UI
seems
seems
way
better
than
kind
of
like
kind
of
having
all
of
the
users
having
those
permissions
and
everything
so
standing
for
point.
One.
E
H
Access
in,
like,
let's
say,
development
clusters
and
everything
but
like
this
is
more
like.
We
don't
want
people
to
actually
go
into
the
habit
of
like
editing
resources
in
the
dashboard
and
everything
and
then
not
reflecting
those
changes
back
into
the
source
code.
That's
that's
just
for
those
kind
of
cases
here
like
like
you
know
to
me:
it's
like
the
the
art
back
of
whatever
you
have
in
in
the
cube
control.
Is
your
art
back
right?
If
you
can,
edit,
you
can
edit
okay.