►
From YouTube: SIG Cluster Lifecycle 2020-10-20
A
A
But
basically
there
are
a
number
of
fixes
that
fix
problems
around
that,
like
you
can
see
the
links
we
fixed
the
number
of
cvs,
for
instance
like
this.
This
one
is
interesting:
the
cube
api
server
at
level
more
than
nine
prints,
some
sensitive
details-
and
I
ask
the
question
here
like
ok:
we
have
a
guide
about
k,
log
levels
which
claims
that
everything
above
level
three
is
the
bug
information.
A
A
A
A
C
B
Yeah
I
was
going
to
echo
similar
things
and
you
know,
while
we
can
make
recommendations,
the
user
is
not
running
a
higher
level
of
debug
there's
going
to
be
cases
where
users
hit
issues
and
for
one
reason
or
another,
going
to
need
to
enter
a
higher
level
of
debug
to
be
able
to
like
feed
back
issues,
and
if
they
are
capturing
that
and
other
software
you
know,
then
it
becomes
a
continued
issue
that
will
crop
up.
So
I
don't
think
we
want
to
rely
on
debug
level.
B
A
D
Can
you
hear
me
better
now?
Yes,
okay,
good,
I
was
gonna
say
it's
only
secrets,
tokens
things
like
that
that
can
actually
grant
permission
that
we
are
filtering
or
removing.
It
is
not
things
that
make
it
easier
to
hack
like
addresses,
and
it's
not
things
like
pii
like
ip
addresses.
I
don't
think
as
far
as
I've
seen
there
hasn't
been
anyone
obscuring
those.
It
is
only
credentials
or
credential
equivalents.
A
Yeah,
so
I
wanted
to
make
clear
that
this
is
not
like.
We
don't
have
really
an
argument
against
the
I.
I
just
wanted
to
get
feedback
from
this
group
and
maybe
make
this
like
a
announcement
that
things
nowadays
being
treated
as
cvs
if
you
print
the
secret
by
mistaking
your
locks,
it's
a
cve.
So
this
is
the
psa
here
pretty
much.
A
C
Sorry
there
was
a
comment
I
saw
on
on
twitter
that
maybe
in
the
code,
if
you
use,
if
you
define
types
for
things
like
passwords
and
tokens
that
that
by
default
obscure
like
their
their
their
string,
conversion
method,
prints
asterisks,
for
instance,
that
that
can
kind
of
help
people
do
the
right
thing.
I
don't
know
if
we
wanna,
I'm
not
sure
if
we
own
that
level
a
little
bit.
Maybe
we
own
frameworks
like
that.
This
is
kind
of
next
level
up,
isn't
it
controller
runtime?
That
kind
of
thing.
A
D
D
Useful
because
then
you're
never
gonna
like
accidentally,
pass
a
docker
token
to
a
like
rbd
credential
right.
It
provides
it's
actually
a
really
standard
practice
that
we
haven't
done
in
go
because
it's
sort
of
considered
discouraged.
I
guess
I
think
also
one
of
the
challenges
with
that
is
that
I
believe,
if
you
print
the
structure,
it
doesn't
call
the
printer
on
the
fields.
I
could
be
wrong.
D
The
string
function
on
the
fields
in
in
any
case,
though
I
imagine
this
would
be
a
security
thing
now
that
we
have
that
sake.
That
should
be
proposing
that
sort
of
thing,
but
we
can
certainly
like
suggest
it's
a
great
suggestion,
and
I
think
we
should
certainly
bring
it
to
them,
and
we
did
it.
We've
done
it
successfully
in
the
past,
where
we've
had
strings
that
could
easily
be
confused,
like
I
did
node
name
and
an
instance
and
hostname
for
example.
That's
why
those
two
types
exist.
A
Yes,
if
you
have
any
suggestions,
you
can
add
them
to
the
google
groups
discussion.
I
guess
I'm
hoping
that
seek
security
will
be
watching
this
topic,
and
maybe
members
of
seek
security
can
reply
but
yeah.
This
is.
This
was
just
the
discussion
here,
I'm
hoping
that
we
don't
have
components
that
will
have
cvs
eventually
for
this,
for
something
like
that.
A
A
E
A
Ago
we
we
discussed
that
question.
Api
should
eventually
be
a
project
that
blocks
the
kubernetes
release,
so
the
kuster
api
providers
were
placed
as
releasing
forming,
which
is
the
first
step.
Eventually
it
can,
they
can
become
released.
Blocking
the
problem
here
is
that
if
these
providers
don't
maintain
their
end-to-end
signal,
we
should
just
remove
them
from
releasing
forming,
because
otherwise
we're
going
to
get
like
requests
from
the
release
team
constantly
to
fix
them
agree.
E
Yeah,
okay
and
I
saw
in
the
in
the
configuration
for
cap
g.
There
is
a
lot
of
other
jobs
like
similar
to
v1,
alpha
3,
but
for
v1,
alpha
2.
and
looking
the
repo
for
capital.
I
didn't
see
like
the
api
alpha
2
should,
like
we
open
up
here,
to
clean
up
this
pro
config
jobs
or
I'm
missing
something
that
I'm
not
aware.
B
B
A
A
F
E
A
A
A
A
A
Apparently,
this
is
quite
a
quite
of
a
mess
in
core
kubernetes
today,
so
we
have
a
couple
of
pending
prs
if
you're
interested
have
a
look,
these
are
for
cube,
adm
and
also
for
core
components
in
terms
of
fixing
the
docks
at
least
the
one
of
the
flags
from
the
kcm.
That
is
the
I
believe
note
cider
mask
it's
very
problematic,
because
it's
it
makes
some
assumptions
around
the
coastal
cider.
You
pass
it's
bound
to
the
quest
side
of
whack,
it's
a
bit
of
a
mess.
A
F
F
F
We
are
running
to
get
the
v0311
release,
which
is
ready,
which
is
planned
for
the
first
week
of
november,
and
basically
the
two
teams,
or
the
two
changes
that
that
are
filled
with
in
this
into
these
release
are
an
improvement
on
condition.
So
we
are
adding
non-condition
on
machines
or
it
is
written.
F
F
A
G
Hi
yeah
there's
one
one
thing:
that's
kind
of
interesting:
there
was
a
request
to
to
implement
phases
so
in
the
same
way
that
kubidium
has
phases-
and
this
came
out
of
the
use
case-
of
using
xcd
nfc
cuddle
binaries
that
are
installed
from
a
different
source
like
a
system
package
and
that
would
require
relieving
at
cd
adm
of
the
responsibility
of
of
installing
the
binaries
and
uninstalling
them.
So
the
phases
there
it
made
made
sense,
there's
a
little
bit
of
discussion
in
that
in
that
pr.
G
D
A
Yeah
we
have
a
bit
of
a
lesson
learned
from
phases
in
the
land
of
cubadm,
the
more
you
expose
to
the
user,
the
more
you
have
to
not
break.
So
if
you
expose
commands
phases
for
this
separate
sub-actions,
you
have
to
be
careful
like
what
is
stable.
What
is
not,
I
would,
I
would
only
expose
the
stable
parts
of
the
actual
command.
So
if
you
have
concerns
about,
for
example,
the
if
the
part
about
generated
certificates
is
currently
unstable,
it
may
change
in
the
future.
A
If
you
expose
it
as
a
command,
you
have
to
apply
some
rules
for
this.
Okay,
we
expose
this
command,
but
it's
alpha.
Is
it
or
a
phase
it's
alpha
and
we
can
break
the
consumer
if
they
are
not
careful
once
you
graduate
this
command,
we
give
you
a
guarantee
that
we
are
not
going
to
break
it.
So
that's
basically
the
tldr
there
nowadays
in
cuba,
it's
really
hard
to
change
the
face
order.
The
face
contents
so
like
this
is
just
a
you
know
like
a
warning
that
you
should
be
careful
about
such
feature.
A
D
So
I
I
I
want
to
continue
doing
it
and,
I
think,
there's
an
argument.
I
think
we're
still
experimenting
as
to
what
the
right
way
to
achieve
that
to
achieve
some
of
these
things.
It's
it's
it's
not
necessarily
like.
Should
we
change
our
structured
meetings,
the
cult
structured
meaning,
for
example,
to
better
encompass
this,
or
should
we
have
some
ongoing
random
state
cluster
lifecycle,
hangout
fun
meeting
where
we
talk
about
random
stuff,
that
is
across
projects
that
isn't
as
easy
to
bring
up
here
that
you
know
we
don't.
D
A
D
Do
we
want
to
change
the
way
they
behave
and
therefore
risk
having
to
sort
of
think
about
them
again
or
do
we
want
to
risk
everything
about
them
because
we
break
them
or
do
we
want
to
potentially
break
them
or
do
we
want
to
just
get
everyone
onto
the
new
thing
and
not
have
to
worry
about?
You
know
the
sort
of
split
behaviors.
D
A
Yeah
I
see,
but
if
I
join
a
hackathon,
I
honestly,
I
wouldn't
expect
that
I
have
to
write
something
like
a
kip,
maybe
it's
a
too
much
but
like
today
I
realized
that
the
project
called
helm
was
created
during
a
hackathon,
so
maybe
design
decisions
and
big
ideas
also
can
be
a
product
of
a
hackathon.
So
but
if
something
is
if
if
the
hackathon
is
like
or
why.
F
D
A
Scope
is
more
about
lightweight
changes.
Maybe
you
just
have
to
scope
the
hackathon
itself
like
saying
hey,
we
are
only
going
to
touch
small
issues
here.
Small
features,
it's
a
big
designer
factors
and
things
like
that
are
really
in
the
scope
for
the
project
timeline
itself,
not
the
hackathon
timeline.
D
Has
played
out
is
that
the
people
that
are
attending
meetings
are
generally
people
from
the
existing
community.
There
are
a
handful
for
these
examples.
There.
There
are
a
few
have
prs
that
have
come
in
from
new
contributors.
I
don't
think
we've
seen
them
show
up
to
the
the
informal
chat
sessions.
Yet
generally,
there
are
some
existing
contributors
that
are
able
to
attend
because
of
the
different
times
of
you
know
being
not
friday
afternoon
in
europe
type
thing,
but
it
is
not
it
is.
A
I
see
so
so
it's
a
mixture
between
existing
contributors
and
new
contributors.
Of
course,
we
are
more
interested
in
terms
of
the
goal
main
goal
of
the
event.
We
are
more
interested
about
the
new
contributors,
because
this
is
like
we.
This
is
how
we
are
going
to
attract
more
people,
but
it's
really
a
difficult.
It's
a
difficult
decision
where,
whether
where
to
draw
the
line
in
terms
of
what
is
acceptable
for
the
event
itself
and
what
is
acceptable
for
the
main
project
development
cycle,
I
really
don't
have
a
good
answer
for
that.
A
Yeah,
it's
a
it's.
I
don't
know
it's
finding
the
balance.
Also,
if
you,
if
you
can
create
the
list
of
potential
tasks
beforehand,
maybe
and
say:
okay,
this
is
only
what
we
are
going
to
work
on.
Maybe
that's
like
this
scopes,
the
hackathon
itself,
so
you
know
that
all
the
tasks
are
going
to
be
maybe
easier
and
you
can
leave
the
design
design
decisions
outside
of
the
event
itself.
Maybe
I
mean
this
is
just
brainstorming
on
the.