►
From YouTube: Octant Community Meeting - June 23rd, 2021
Description
Octant community meeting is held weekly. We discuss and talk about the current state and future of Octant, demo upcoming features and releases, and preview new ideas we are considering for Octant.
Meeting agenda: https://hackmd.io/CzaPxtmXT_SW8nEpdwvGzw?view
A
Thank
you,
everyone,
who's
joining
now,
and
everyone
who's
watching
directly.
Remember
that
we
have
an
open
agenda,
so
please
go
there
and
have
your
name.
This
is
especially
useful
for
persons
who
are
watching
the
recording
of
the
session.
A
A
B
B
Cool
I'll
take
it
away
from
here
then.
B
All
right,
so
this
is
what
often
looks
like:
let's
go
into
our
release
information,
let's
see
the
unreleased
changes
or
relation
of
clickfunnel.21.
Oh,
this
actually
navigates
me
in
the
browser,
that's
kind
of
awkward,
okay.
Well,
here's
what
I'll
do.
B
Changelogs
all
right
here
we
are
so
I
got
half
the
screen
on
octa
and
the
other
half
on
these
releases
and
large
things
to
go
through.
So
there
are
a
few
items
up
here
which
are
of
interest
the
first
one
I'm
not
going
to
go
through
the
forms
forms,
and
I
think
milan
is
going
to
show
the
resource
viewers.
I
think
the
main
highlight
here
is
to
show
the
local
path
that
you
can
take.
So
mainly
you
can
pretty
much
see
this.
I
believe
it's
in
preferences,
so
we
could
this
preference
path.
B
Now
you
get
this
home,
cube,
config
and
yeah.
This
is
just
a
nice
addition
where
you
can
essentially
know
right
away
where
octan
is
trying
to
look
for
your
q,
config
or
multiple
cube
configs,
there
is
yeah
go.
Some
of
the
other
changes
going
through
here
are
the
managed
fields.
So
if
we
go
into
say
an
arbitrary
pod,
I
don't
have
a
pod
here,
so
maybe
I'll
go
into
like
a
certain
manager.
B
B
We
have
this
select
file
component.
So
if
we
go
to
something
like
control
y,
we
have
this
thing
that
just
lets
you
open
stuff
and
close
things
and
apply,
and
essentially
you
can
open
a
yaml
file
here
and
then
add
support
for
cds
cards
for
alerts
models.
So
this
one
is
more
of
a
clarity
thing.
Essentially
we
added
so
instead
of
having
only
just
a
global
alert
now
we
have
alerts
that
are
just
available
as
consumption
for
multiple
places.
So
an
example
of
this
would
be
something
like.
B
Let
me
hide
this
a
little
bit
here.
In
fact,
this
is
covering
the
screen,
so
it
look.
It
would
look
something
like
I
have
this
pod
and
let's
say
I
delete
it
now.
This
cds
alert
is
available
here
within
this
card
and
we
just
made
this
available
as
part
of
the
components
that
people
can
consume
and
add
tabs
as
components.
B
That's
pretty
straightforward,
so
essentially,
tabs
themselves
are
now
first
class
components,
so
you
could
theoretically
add
a
tab
inside
this
flex
layout
or
you
can
use
the
previous
api
through
the
plugins
and
add
additional
apps
out
here
so
and
you
can
do
sort
through
all
sorts
of
crazy
stuff
like
nested
tabs,
but
if
it
ever
gets
that
weird
kind
of
all
bets
are
off
and
you're
kind
of
on
your
own
there.
B
So
that's
brief
overview.
I
didn't
touch
any
of
the
resource
viewer
things,
so
I
can
hand
that
off
since
milan's
been
working
on
it.
A
Thank
you
so
much
sam.
There
was
a
teacher
there
that
here
in
college
with
claude
rosenberg,
he
is
thank
you
for
joining
is
one
of
the
long
time
users
and
I
know
he
was
waiting
for
the
cubeconfig
path
feature.
So
I
hope
you
will
find
it
useful.
C
No,
it's
awesome
that
it's
there.
It's
really
helpful,
especially
on
windows,
where
it's
hard
to
know
where
it's
saved
so
definitely
awesome
to
have
that.
A
Thank
you.
Thank
you,
okay,
so
let's
go
ahead
and
please,
with
milan,
he's
going
to
show
us
some
of
the
new
features
in
the
resource
viewer.
D
I
had
a
quick
question
about
the
yaml
viewer,
the
apply
or
the
the
browse
for
file.
Does
that
get
shown
when
you
start
up
octant
without
acute
config
to
let
you
browse
and
select
a
cubeconfig.
E
I
just
wanted
to
show
briefly
the
resource
viewer
and
I
mean
I
showed
most
of
those
features
at
the
time
they
were
developed
mostly
to
get
some
feedback,
but
now,
since
they're
released,
it's
a
good
time
to
go
back
and
show
them,
and
I
will
display
something:
that's
usually
done
demo
and
that's
web
hooks
that
contain
different
components.
So
it's
a
different
resources.
So
it's
a
little
easier
to
to
to
show
the
variety
of
changes
we
have
in
this
release.
E
E
But
in
this
release
one
of
the
changes
is
that
when
you
open
this
view,
the
the
resource
you
are
viewing
will
always
be
selected,
which
is
important.
So
it's
a
small
change,
but
it's
important
for
multiple
reasons.
It
highlights
that
selection.
It
highlights
what
you're
working
on,
but
also
it
automatically
shows
the
properties
on
the
right
side.
That's
another
feature:
that's
new.
E
In
this
release
for
each
resource
we
will
display
a
list
of
properties,
and
that
list
varies
depending
on
the
type
of
resource,
so
the
one
we
see
right
now
is
out
of
the
box
default
that
shows
for
every
resource.
In
this
case,
this
is
a
custom
resource
that
we
don't
have
much
more
information,
so
we
only
show
the
version
kind.
E
Since
this
is
a
cluster
scoped,
there's
no
namespace
and
created,
you
can
see
right
away
that
those
are
components
on
the
right
side
so,
for
example,
the
created
as
a
timestamp
component
and
in
the
future
we
I
can
envision
in
some
other
places
which
we
display
links,
but
in
future
those
components
might
be
maybe
spark
charts
or
progress
controls
when
we
have
those
or
any
other
component
for
that
matter.
E
So
for
different
resources,
for
example,
for
services,
we
try
to
highlight
the
most
important
things
about
that
resource
so
service.
It's
obviously
important
what
kind
of
resource
it
does
on
session
affinity
and
so
on
for
conflict
maps.
We
don't
have,
for
example,
for
states
full
sets.
We
should
number
of
replica
sets
and
board
management
policy,
and
so
on.
I
don't
want
to
go
into
many
details.
We
also
display
for
pods,
for
example,
that
are
pretty
important
resources.
E
E
This
can
come
from
a
plug-in
as
well,
and
I
have
this
sample
plug-in
that
registered
for
this,
and
it's
displaying
the
id
just
for
example,
so
it
you
can
see
that
properties
can
be
controlled
on
multiple
levels
and
they
they're
configurable
and
they're
accessible
from
from
plugins,
and
let
me
just
quickly
show
one
other
thing,
so
we
have
here
one
application
that
has
some
issues.
E
I
don't
know
what's
going
on
with
this
gym,
but
yeah
every
time
I
run
things
and
some
things
are
so
slow,
so
you
can
see
that
there
are
some
errors
with
this
deployment
and
in
this
case
we
are
showing
the
last
event
and
that
quickly
illustrates
what's
going
on,
there's
a
image
pullback
of
error,
so
this
will
help
diagnosing
and
troubleshooting
errors.
One
other
thing
I
wanted
to
show
is
this
properties.
E
E
Yeah,
that's
that's
briefly.
Some
of
the
improvements
we
have
a
resource
viewer
getting
more
work
here,
especially
with
collapsing
expanding
nodes
and
that's
coming
in
0
22.
D
I
just
when
you're
looking
at
the
pod
and
and
you
see
the
pre
the
last
event
that
was
in
there
is
that
something
is
that
clickable.
Oh.
C
E
And
you
can
see
the
involved
object.
Oh
I
clicked
it's
back,
I'm
sorry!
You
can
see
the
involved
objects
and
start
troubleshooting
from
there
yeah
in
the
future.
We
may
show
some
other
stuff
there.
So
if
you
have
any
suggestions
or
ideas
always
open
for
that,
especially
this
kind
of
stuff,
because
it's
really
hard
to
know
what
what's
important
for
each
resource
type,
so
yep.
A
So
next
item
is,
you
know,
there's
a
couple
of
issues
philippe
and
victor
have
been
working
really
hard
to
oppose
to
a
complete
solution,
especially
this
one
is
related
to
a
bug
reported
by
a
user.
G
G
Basically
they
are
the
same.
They
are
some
uncompatibilities
between
octa
and
the
api
from
kubernetes.
So
this
morning
I
was
talking
with
vikram.
We
are
thinking,
maybe
doing
some
like
different
apis
yeah
so
to
to
be
able
to
support
different
apis
right.
So
I
would
like
to
know
what
you
guys
think
if
this
is
a
good
solution,
if
not
what
could
be,
but
that's
what
we
have
in
mind.
D
Yeah,
so
I
think
I
I
think
it
might
have
been
this
issue
or
a
different
one.
I
left
the
comments.
I
do
think
we
want
to
be
supporting
the
different
versions
of
the
resources
until
they
fall
out
of
our
version
support
matrix
for
kubernetes.
Essentially,
so,
if
you
take
a
look
at,
I
is
it
this
issue.
D
Yeah
so
there's
the
link
to
our
supported
version,
sku
policy,
which
says
we
support
the
current
version
plus
two
back
and
then
there's
the
deprecation
guide
from
upstream
kubernetes,
which
kind
of
states
when
things
have
been
promoted
from
v1
beta
to
v1,
when
they
are
going
to
be
getting
removed,
and
in
the
case
of
ingress,
when
the
kubernetes
main
version
is
at
0.24
or
sorry.
I
put
o,
because
I
was
thinking
in
octane
terms
but
1.24.
D
That
is
when
we
would
completely
drop
support
for
it
in
octant,
because
we
that
it's
no
longer
two
versions
back
because
for
122,
it's
it's
by
122,
it's
it's
removed
completely.
So
so
I
do
think
we
want
to
support
multiple
versions.
D
I
think
we
want
to
use
this
deprecation
guide
as
a
reference
for
what
is
basically
kind
of
our
source
of
truth
for
saying
yes,
we
support
that
version.
Here's.
Why
or
no
we
don't
here's.
Why?
Right
like
you're
you're,
like
you,
have
to
upgrade
at
this
point.
If
you
want
to
be
able
to
see
that
resource
and
by
following
this
deprecation
guide,
it
also
puts
us
in
a
good
position
where,
since
folks
are,
are
going
to
have
to
upgrade.
D
Basically
it
puts
us
in
the
right
upgrade
path,
so
people
using
people
would
not
be
able
to
use
octan
against
an
older
cluster
and
see
those
older
resources,
but
they
also
wouldn't
be
able
to
take
those
resources
they
have
and
move
them
to
the
newer
version,
because
it
would
require
them
to
make
changes
to
their
resources
and
actually
do
the
the
upgrade
process.
So
that's
kind
of
that's
kind
of
where
I
landed
on
this.
D
I
think
I
think
there
might
be
a
couple
other
issues
or
not
issues
but
resources
that
we've
kind
of
dropped.
Support
for
that
that
we
might
want
to
go
back
and
add
support
for,
but
most
I
think
ingress
is
the
only
one
we
get
constant
issues
on.
I
think
there's
three
total
now,
as
people
have
upgraded
their
versions
of
octant,
so
anyway,
that's
yeah.
D
I
encourage
people
to
go,
read
that
deprecation
guide,
as
it
has
some
great
info
about
when
certain
versions
of
resources
are
going
to
be
going
away.
F
E
I
I
like
that,
I'm
just
wondering
you
know,
since
this
is
it
for
users
that
are
running
the
old
versions
of
bernat
is
this
is
a
little
harder
to
it's.
It's
a
little
harder
to
use
outside
trades.
So
I'm
wondering
do
we
have
any
data,
you
know,
what's
the
percentage
wise
who
is
using,
you
know
21
or
24
or
18
or
any
other
versions?
Do
we
do
we
have
any
data
on
that
and
how
important
it
is.
D
We
don't
have
any
data
on
that,
but
what
I
can
say
is
that
the
folks
who
have
reported
their
problem
with
ingress
are
not
using
what
I
would
call
very
old
versions
of
kubernetes
at
all
they're,
using
either
one
version
or
two
versions
back
which
both
still
support
b1
beta
1
for
ingress
and
we'll
continue
to
support
it
until
0.22,
like
oh,
not
22
or
1.22
for
kubernetes
is
when
it
will
officially
be
dropped
so
that
that's
going
to
be
fairly
soon,
but
the
for
us
as
a
project.
D
We've
stated
that
we
support
the
current
version
plus
two
back.
So
that's
on
us
to
ensure
that
people
running
two
versions
old
of
kubernetes
can
can
function
when
using
octane.
I
think
that's
a
that's
a
burden
that
we
took
on
as
a
team
and
decided
that
that
was
a
reasonable
thing
to
say
was
two
versions.
D
Current
version
plus
two
version
back,
and
so
it
really.
I
guess
it
really
doesn't
matter.
What
I
guess
is
the
end
of
it
right
like
the
work
that
we
are.
I
I
feel
very
strongly
that
it
is
reasonable
to
say
we
support
the
current
minus
two
people,
don't
upgrade
their
clusters
with
every
single
release.
In
fact,
a
lot
of
people
intentionally
wait
for
a
release.
D
They
drag
a
release
very
intentionally,
and
a
lot
of
the
cloud
providers
also
intentionally
drag
their
releases
so
yeah.
I
think
I
think,
there's
no
way
around
it.
We
just
kind
of
have
to
to
support
these
things
and
honestly,
the
overhead
in
supporting.
It
is
not
not
really
that
much.
I
yeah
it's
I
don't
know
it
doesn't
seem
that
much.
D
D
When
we
have
two
different
versions,
what
should
we
show
and
crds
have
an
example
of
showing
both
versions
of
a
resource
instead
of
instead
of
what
we
used
to
do
was
merge
them
together
and
then
what
you
saw
was
like
v1
ingress,
but
what
it
actually
was
was
v1
beta1
ingress,
and
that
was
confusing
to
people,
so
we
removed
v1
beta,
but
then
that
broke
people
who
hadn't
upgraded,
you
know
updated
their
ingress
resource.
D
Yet
so
yeah
following
the
pattern
of
crds,
where
we
show
you
the
real
version
and
list
them,
I
think
is,
is
ultimately
where
we
want
to
end
up.
C
E
C
It's
that's
also
the
exact
same
skew
as
I
used
to
use
quintana
lens,
also
as
another
one
who
used
that
same
skew
of
two
versions
and
until
the
api
version
isn't
supported
anymore
in
kubernetes.
So
I
think
that
it's
also
good.
There
is
precedence
for
that
same
skew
in
client-side,
octant,
visualization
tools,
and
it
makes
sense.
A
Yeah,
thank
you.
Thank
you
and
everyone.
Okay,
next
topic
in
the
agenda,
you
know
for
the
planning
of
the
upcoming
releases,
I've
been
talking
with
some
of
our
user
community,
one
of
them
being
a
spot
indeed,
and
I'm
just
bringing
here
briefly
some
of
the
feature
requests,
let's
say,
or
some
of
the
issues
stopped
in
the
conspiracy
for
a
future
release
of
option,
one
of
them
being
this
one
15
yeah
1751
the
addition
of
a
terminal.
C
Yeah,
I
think
that,
overall
having
the
terminal
would
be
a
huge
thing
for
cube
ctl.
Basically,
I
think
that,
having
that
ability
to
not
need
to
open
up
the
shell,
especially
now
that
octant
is
an
electron
app
is,
would
be
huge
to
be
able
to
not
leave
the
application
for
things
that
people
want
to
do
cube
ctl,
for,
I
think,
could
be
very
helpful,
similar
to
how
it
exists
in
some
other
tooling
as
well.
C
I
think
that
just
not
needing
to
leave
the
application
would
be
very
helpful
when
you
want
to
run
just
a
simple
cube,
ctl
command
or
something
like
that.
D
Yeah
I
agree
here.
I
think
this
has
come
up
previously
from
other
folks
in
the
community
as
well,
and
I
I
think
sam
even
it
was
it
was.
It
was
pretty
funny
because,
like
sam-
and
I
were
having
a
discussion
about
this
and
then
like
someone
opened
an
issue
for
it
and
then
some
other
people
commented
on
it
and
it
was
like
the
moment
we
the
moment
we
said
it
out
loud
and
like
a
bunch
of
people
were
like.
D
Yes,
we
would
like
to
be
able
to
do
that,
and
I
think
it
was
something
we
even
considered
trying
to
get
in
back
in
like
0.19,
and
it
just
never
made
it
into
the
list
of
priorities
so
yeah.
This
is
it's
good
to
know
I'll
make
sure
it
gets
put
moved
up
in
the
backlog
just
from
community
from
a
community
standpoint
of
people
really
wanting
it,
and
then
we
can
see
which
of
the
next
releases.
It
gets
planned
into.
A
A
So
thank
you
and
finally,
there
is
a
here
appointment
having
a
spring
goal.
I
don't
know
who
exactly
and
put
it
there
so.
D
Yeah,
so
that
was
added
by
me
and
one
of
the
things
that
I
was
interested
in
trying
out
it's
something
that,
in
the
in
various
one-on-ones
with
people
from
the
team
there's
a
common
theme
of
like
people
understand
that
there's
a
cue
of
issues
to
work,
but
they
don't
seem
to
have
like
a
something
that
ties
them
all
together,
something
that
creates
kind
of
a
goal
for
the
current
sprint.
D
And
so
I
was
I
was
wanting
to
kind
of
work
towards,
and
we
don't
have
to
do
it
here
in
this
meeting.
But
I
wanted
to
at
least
start
talking
about
it
so
that
next
week,
when
we
go
to
later
in
this
week,
when
we
plan
our
our
our
sprint
and
we
go
to
kind
of
kick
everything
off
I
want
to.
D
I
want
to
have
a
kind
of
a
summary
that
says,
and
if
people
hate
this
idea,
then
we
won't,
but
my
thought
was,
it
seems
like
people
wanted
it
based
on
feedback.
D
So
my
thought
was
that,
as
a
group,
we
would
come
up
with
kind
of
a
summary
of
what
this
release
is
going
to
focus
on
and
and
be
be
kind
of
specific
about
that
and
then
use
that
to
and
then
establish
like
three
key
outcomes
like
goals
for
the
release
and
then
use
that
to
guide
our
planning
process
when
we're
putting
things
into
o.2022,
because
I
think
what
happens
now
is
we
we
go.
D
D
That's
like
all
like
doing
all
of
the
things
a
little
bit,
instead
of
like
really
like
zooming
in
on
one
thing
and
doing
that
thing
really
well
right,
like
we
have
the
we
have
the
opportunity
to
kind
of
take
a
thing
that
we
really
want
to
improve
and
just
hyper
focus
on
that
thing
for
an
entire
sprint
and
that
that
thing
can
can
be
whatever
we
decide
as
a
team
based
on
community
feedback
and
priorities
and
like
we
can
decide
that,
but
then
making
sure
that,
like
hey
this
issue,
yeah
it'd
be
nice
and
it's
important,
but
it
doesn't
align
with
kind
of
our
summary
and
our
and
our
set
goals.
D
And
then
this
would
also
tie
into
making
sure
that
releases
are
are
landing
like
this
next
release,
which
is
scheduled
for
july
13th
july
13th
is
the
day
we
cut
the
release
and
what
what's
there
is
there?
What's
not
is
not,
and
then
we,
you
know,
move
on
to
the
next
release.
D
So
I
think,
having
a
summary
and
a
focus
for
the
release
and
the
set
of
goals
will
also
help
us
not
drag
releases
like
we
have
been
in
the
past
where
I'll
go.
Oh,
you
know
this
is
this
is
important
and
we
haven't
cut
a
release.
Yet
so,
let's
wait
and
and
now
we
can
say
like
hey
yeah,
it's
important,
but
also
it
doesn't
fit
with
the
the
focus
and
the
goals
that
we've
set.
So
it
it
can
wait.
D
Okay,
thoughts,
comments,
hate,
it
love
it
don't
care.
E
So
I
I
think
that
will
definitely
help
us
be
more
focused
and
and
also
sending
the
message
out
to
all
stick
external
stakeholders.
This
is
what's
coming
out
on
july
14th,
so
they
they
know
and
they're
ready
for
it.
So
I
like
that,
a
lot,
and
I
think
we
should
do
it
before
we
start.
E
A
No
okay,
thank
you.
So
final
point
will
be.
This
is
a
question
from
from
myself
from
a
conversation
that
I
was
having
with
a
user
this
week
he's
facing
some
issues.
You
know
listing
restores
this
because
his
user
has
only
permission
in
a
specific
namespace,
so
it's
looked
like.
That
is
not
an
issue
for
often,
but
my
question
is
not
from
the
open
architectural
point
of
view
how
in
general
often
manage
name
is
pasted
versus
close
to
white
and
resources.
B
I'll,
take
this
one
just
and
just
to
clarify
a
little
bit
by
let's
break
this
down
a
little
bit
so
by
manage.
Do
we
mean
operations
or
do
are
we?
Are
you
more
interested
at
the
api
level
what's
happening
when
we're
making
these.
A
Yeah,
actually
from
the
most
painful
operation
will
be.
They
have
the
ability
to
lead
many
spaces.
There
is.
B
Oh
all,
right,
I
need
to
keep
config.
Oh
heads
up
the
the
config
apply
part.
It
doesn't
use
the
yaml
editor,
so
you
can't
actually
browse
files
for
the
cute
config.
Oh
no,
all
right.
B
B
B
Now
here
on
the
top
right
you're
going
to
see
it
starts
on
default,
because
that's
what
it's
going
to
try
and
if
it
isn't,
there
are
various
knobs.
You
can
do
to
force
it
to
be
certain
namespaces,
but
assuming
that
you
have
access
to
everything
cluster
overview,
then
just
becomes
this
all
namespaces
and
whether
or
not
this
is
a
good
name,
it's
debatable,
but
then
you
get
into
this
view.
Where
now
you
can
see
all
the
non-namespace
scoped
objects,
typically
on
a
cluster
depending
on
our
back
permissions.
B
Most
people
won't
really
have
access
to
this
sort
of
stuff,
and
it's
we're
going
down
the
path
of
something
that's
more
locked
down.
For
example,
if
you
were
just
a
user,
I
don't
really
see
why
you
would
need
to
see
every
single
cluster
role
if
you're,
not
an
admin
which
makes
sense
to
me
right.
So
that's
going
to
be
really
what
octan
is
offering
here
now,
how
do
we?
How
does
it
manage
this
stuff?
B
Well,
let's
take
a
look
for
an
example
right,
like
let's
keep
going
with
this
cluster
role.
I
have
this
addressable
resolver.
I
don't
know
what
it
does.
I
could
certainly
have
a
delete
operation
here.
These
cluster
rules
are
objects,
like
any
other
kubernetes
object.
So
I
could
theoretically
update
this
yaml
and
I
mean
it's
here:
it's
just
a
role,
so
it's
not.
I
don't
expect
it
to
be
connected
to
anything
and
pretty
much.
That's
really
it
in
a
nutshell.
B
If
there
are
certain
objects
which
have
specialized
actions,
they
might
be
able
to
be
thrown
here
like,
for
example.
Well,
I
I
think
most
of
these
will
only
have
to
be.
I
can't
really
think
of
a
good
example
off
to
my
top,
my
head,
where
one
of
these
cluster
scoped
objects
have
specific
actions
to
them.
Like
a
good
example
here
would
be,
if
we
go
into
maybe
not
services,
let's
find
something
with
an
act
with
a
real
action
like
a
deployment.
B
Okay,
maybe
not
deployment
but
like
if
you
look
at
say
deployment.
Something
that
one
could
expect
to
see
here
would
be
something
like
rollout
right
like
if
you
wanted
to
spin
an
update
to
a
deployment
and
slowly
roll
them
out
to
like
maybe
half
the
pods.
That
could
theoretically
be
an
action
here.
It'd
be
interesting
to
see
something
like
edit.
I
think
the
only
ones
that
we
really
have
are
like
cron
jobs.
Maybe
there
would
be
stuff
on
notes.
B
Yeah,
so
I
don't
even
think
we
have
node
operations
here
so
yeah,
so
really
that's
about
it.
Nodes
are
also
cluster
scopes,
so
you
can
kind
of
see
like
you
can
even
start,
like
peeling
back
the
infrastructure
layer
and
start
seeing
things
about
the
actual
vms
that
your
cluster
is
being
hosted
on
as
well.
So,
but
as
far
as
whether
or
not
octa
should
be
able
to
manage
something
like
that,
that's
you
know,
I
would
say
it
shouldn't,
but
that's
up
to
opinion.
I
Actually
I
have
one
sam.
You
had
just
brought
up
the
notes.
C
Again
there-
and
I
know,
there's
been
an
issue
for
a
long
time
hanging
about
adding
an
action
for
draining
a
node
right
and
I
didn't
know
if
that's
something
that's
planned
or
not
having
the
ability
to
like
cordon
or
to
drain
a
node.
Basically,
I
know
that's
something
that
I've
been
asked
by
a
lot
of
people
that
I've
pointed
towards
octane
didn't
know.
If
that's
something
that's
planned
at
all.
B
Yeah,
so
it
is
planned
and
I
think
drain
is
technically
a.
I
don't
remember,
which
one
no
drain
is
the
one.
That's
not
I
think
cordon
is
implemented
just.
I
think
there
are
a
lot
of
nuances
there.
Just
simply,
it's
not
just
like
oh
start,
killing
all
the
process
on
this
node
and
moving
it
over
to
the
next
one.
B
There
are
things
like:
oh
what
happens
if
what
should
happen
if
the
process
doesn't
want
to
stop-
or
I
don't
have
the
context-
actually,
I'm
probably
not
I'm
not
explaining
it's
very
well,
but
there's
more
like
it's
not
just
like
add
an
action
and
let
client
go.
Do
the
heavy
lifting
there's
a
lot
of
tunable
parameters
to
this,
which
makes
it
a
little
tricky
to
just
add
a
button
for.
C
It
okay
yeah,
it
has
a
lot
of
if
you
want
it
to
evict
empty
deer
volumes,
and
things
like
that.
There
are
a
lot
of
flags
to
drain
for
advanced
settings.
C
Right,
which
I
guess
that
would
also
be
something
that,
if
there,
if
the
terminal
gets
put
in,
that
would
be
something
that
becomes
much
easier
with
just
cube
ctl
drain
node,
then,
for
those
things
that
are
more
complex,
having
the
easy
escape
patch
because
draining
you
could
technically
do
also
by
editing
the
ammo
which
I've
done
before,
but
that's
less
optimal.
B
Yeah
I'd
say
like
for
these
type
of
operations,
like
my
gut
instinct,
is
to
do
it
on
the
command
line,
just
simply
because
those
flags
are
just
much
more
obvious
and
much
more
well
documented
than
like.
I
think
this
is
one
of
the
cases
where
having
a
ui
might
not
actually
be
helpful.
That
said,
we
could
even
create
a
like
a
very
specialized
view
just
for
this
operation.
B
I
could
definitely
see
this
as
a
thing
just
simply
because
when
this
issue
was
open,
I
think
the
implementing
stuff,
like
forms
we're
still
in
a
very
early
state,
and
we
could
have
a
much
more
guided
experience
for
something
like
this.
C
Yeah,
I
think,
there's
like
five
flags
that
can
be
passed
into
drain.
That
would
be
the
like
form
in
that
case,
and
then
the
defaults
would
be
what
the
default
is
from
like
if
you
were
to
do
a
cube,
ctl
drain
node,
so
it
wouldn't
by
default,
evict
empty
gears
or
wouldn't
evict
host
paths
and
things
like
that,
and
then
it
could
be
just
like
a
checkbox
of
evictor's
path.
Ignore
demon
sets
things
like
that.
A
Okay,
well,
thank
you
so
much
I
don't
know
there
is
not
any
additional
comment
or
questions.
I
would
like
to
thank
scott
rosenberg
for
your
feedback
is
really
useful
for
us
in
the
project
and
we
hope
to
to
keep
you
here
engaged
with
the
with
the
tool
with
the
project
the
community
and
to
everyone
here.
Thank.