►
From YouTube: Kubernetes Meet Our Contributors 20190501
Description
When Slack seems like it’s going too fast, and you just need a quick answer from a human...
Meet Our Contributors gives you a monthly one-hour opportunity to ask questions about our upstream community, watch interviews with our contributors, and participate in peer code reviews.
Check out this page for more information: https://github.com/kubernetes/community/blob/master/mentoring/meet-our-contributors.md
A
Hello,
everyone
and
welcome
to
may
I
can't
believe
it's
May
already
is
edition
of
meet
our
contributors.
We
do
this
song
and
dance
twice
a
month
on
the
same
day,
first
Wednesday
of
the
month
and
today
being
no
different.
We
have
awesome
contributors,
early
contributors
for
kubernetes
with
us
today
that
are
going
to
help
you
with
all
of
your
upstream
questions,
concerns
comments
and
anything
that
you
would
ask
a
mentor.
That's
what
we're
here,
for
we
also
have
a
code
based
tour
for
cute
control.
A
Some
say
cube,
cuddle,
I'll,
say
both
and
that's
gonna
be
a
really
awesome.
Adventure
for
us.
We've
been
doing
Co
based
tours
on
this
program
as
well
for
some
time,
and
we
get
a
lot
of
positive
feedback
for
visual
learners.
So
that's
awesome.
First
things.
First,
we
always
start
with
the
rules.
Rules
of
engagement
or
we
do
have
a
code
of
conduct
here
that
we
abide
by
that
is
located
in
our
github
repo.
If
you'd
like
to
check
that
out,
TLDR
is
be
excellent
to
each
other.
A
A
B
My
name
is
Michiko
leak,
I
go
under
sottish
on
github,
and
you
also
find
me
pretty
much
the
same
on
Twitter.
So
if
you
want
to
follow
both
my
work
and
what
I
tweet
about
feel
free
to
to
follow
me,
I
work
for
Red,
Hat
and
I'm
involved
in
the
gratis
for
I.
B
A
C
C
Since
then,
when
we
started
the
cigs
I
was
a
lead
and
sig
off
and
in
API
machinery,
I've
stepped
away
from
sig
off
now
still
still
console's
in
the
background,
but
I
am
still
a
co-lead
on
API
machinery.
We've
brought
in
lots
really
interesting
things.
Some
are
public
that
people
all
see,
you'll
notice,
custom,
resource
definitions,
for
instance.
Some
are
less
well-known.
We
are
the
people
behind
informers
and
all
the
things
that
backing
them.
It
came
before
them
the
work,
queues
and
stuff
that
you
use
for
for
building
controllers
as
well.
C
C
A
A
C
Gonna
sound
I,
I
guess
I'll
go
first
much.
It
was
on
mute
odd.
It
was
just
dumb
luck.
There
was
a
team
at
Red
Hat
that
was
working
on
over
shift.
They
were
considering
how
weather
and
how
they
would
integrate
with
kubernetes
kubernetes
was
still
really
young.
It
had
just
been
open.
Sourced
I
got
a
call
from
a
friend
when
I
had
a
bad
day
at
work.
I
was
working
at
IBM
at
the
time
and
he
asked
you
want
gonna
work
with
me
and
I
said.
C
You
know
what
sure,
and
at
that
point
the
choice
was
random
and
since
then
it
was
about
nine
months
or
so
hard
work
to
OneNote
and
I
saw
it
really
taking
off
the
next
year
or
so,
and
it's
been
interesting.
I
get
to
build
the
platform
from
the
ground
up
and
I
have
been
in
the
business
a
long
time,
I've
never
gotten
to
build
a
successful
platform
from
scratch.
Many
unsuccessful
ones,
but
never
successful
I.
B
Mean
the
path
was
pretty
much
similar
I
mean
I
was
at
the
point
in
time
in
my
life,
where
I
wanted
to
look
for
something
different
and
we're
actually
two
positioned
that
I
was
applying
for
at
Red
Hat
back
then,
and
both
are
actually
dear
to
my
heart.
One
was
Python
related
and
you
can
ask
literally
anyone
that
knows
me
and
see
David
laughing
I'm,
always
Python,
since
my
college
days
and
I
was
applying
for
that
and
at
the
same
time
there
was
the
open
shift
position.
B
About
Python
I
was
a
lot
for
for
Python
I
I
took
a
break
and
actually
with
my
crying
card,
there's
a
plugin
happening
currently
in
Cleveland
and
I
have
a
deal
with
my
wife
that
every
other
year
I
can
go
to
Pike
on
us,
and
actually
this
would
be
the
year
that
I
would
be
going.
So
this
is
super
hard,
hard
fearful
feeling
for
me,
because
I
can't
be
there.
I'm
gonna
miss
Cleveland
entirely,
but
I'm
flying
definitely
next
year
for
Baltimore.
B
So
if
you're,
if
you
want
to
talk
Python
during
Q,
Khan
feel
free
to
find
me
or
tweet
at
me
or
the
other
way
around.
If
you
will
be
able
on
pike
on
next
year
and
you'll
find
me
there,
I'm
always
he's
defined
because
I'm
one
of
the
person
at
swag
booth,
along
with
the
awesome
team
there
so
yeah
I'm,
still
booked
because.
A
You're,
an
awesome
community
member
number,
one
so
yeah
we
all
get
the
conference
FOMO
I,
know
a
lot
of
people
that
aren't
making
it
out
to
Barcelona.
That
already
are
feeling
the
cube
from
Barcelona
FOMO,
but
it's
super
cool
that
you
also
date,
the
Python
community.
That's
definitely
a
good
community,
all
right
question
and
DM.
A
So
how
did
you
get
up
to
speed
and
work
your
way
up
to
a
maintainer
which
we
technically
call
sub
project
owner,
which
we
can
talk
about
later
so
essentially
I
they're,
pretty
much
saying
that
this
is
a
pretty
large
and
complex
project.
So
how
did
you
get
up
to
speed?
I
mean
obviously
working
full
time
probably
helps,
but
what
were
some
of
the
other
ways
and
maybe
even
relaxed
a
unit?
So.
B
This
is
how
I
got
involved
in
this
a
gaps
and
I'm
still
active
and
the
sake
application
most
be
working
around
batch,
which
is
both
jobs
and
cron
jobs,
a
little
bit
of
the
other
controllers,
but
not
that
much
and
then
over
time.
There
was
a
need
for
me
to
dive
into
the
queue
of
CTO
and
on
the
way
there.
I
was
also
touching
a
little
bit
of
API
missionary
here
and
there
that's
probably
one
of
the
reason
that
I'm
working
with
David,
so
that
can
get
a
lot
of
his
knowledge
and.
B
B
So
if
you,
if
you
carefully
look
through
our
Charter
you'll
notice,
three
names
being
mentioned
that
will
be
me
and
Phil
are
holding
the
roles
for
tech
leads,
which
means
the
two
of
us
are
responsible
for
the
shape
and
the
technical
direction
of
QTL.
Where,
as
shown
and
myself,
are
holding
the
role
of
organizing
the
sexy
light
meetings
and
thinking's
taking
care
of
the
organizational
side
of
the
special
interest
group
CLI,
everybody.
A
A
B
Very
complained,
like
I,
really
care
about
what
people
think.
Well,
they
are
their
biggest
pain.
You
can
ask
David
I
literally
asked
every
single
person
that
I've
met
and
everywhere
what
is
the
biggest
pain
that
you
are
having
with
cube,
CTO
and
then
I'm
trying
to
work
my
way
through,
so
that
we
can
make
keeps
you
feel
a
better
tool.
B
A
B
C
I've
seen
it
from
the
other
side
right
like
like
matcha
and
I.
We
actually
worked
together
at
Red
Hat,
it's
not
just
to
random
people
like
they
were
written
to
you,
but
we're
on
the
same
internal
team
and
I
can
see
machi
like
internally
he's
getting
upset,
he's
a
little
frustrated,
but
he
doesn't
let
it
spill
over
and
into
the
external
thing
right.
He's
gonna
be
talking
to
the
external
person.
C
C
Think
that
really
it
turns
out
it
just
is
personal:
it's
not
personal
for
the
other
person,
it's
personal
for
you
and
you
need
to
make
sure
that,
even
if
it
is
personal
for
you
you,
you
don't
take
that
frustration
on
the
person
who
is
just
coming
in
and
saying
those
things
they
don't
care,
it's
not
personal
for
them
and
and
I.
Think
matcha
is
really
good
at
that.
B
Learn
from
the
best
like
the
entire
cube
community
and
Python
community
is
so
welcoming,
and
it
has
a
so
positive
vibe
that
you
know
it
just
you
want
to
be
part
of
it
and
you
want
to
even
when
you're
super
mad
I'm
gonna
hide
it
in
your
pocket
and
throw
at
the
wall
back
at
home,
but
at
the
same
time
talk
the
person
inside
of
community
because,
yes,
he
provided
you
a
valuable
feedback.
Even
even
if
you
don't
agree
with
it,
it
does
make
sense.
B
So
you
know
it's
always
weighing
in
and
seeing
how
this
impacts
and
what
we
can
do
resolve
the
use
cases.
We
consult
everyone's
problem.
Obviously
that's
that's
a
normal
thing,
but
there
are
options
that
we
can
help
people
to
overcome
their
obstacles
or
whatnot
and
David
is
like
I,
said,
I
learned
so
much
from
David
in
and
and
other
people
well.
C
B
B
C
Yeah,
it's
it's
been
that
way
since
the
beginning
right
you've,
if
you
look
back,
Roger
was
small
enough.
When
we
joined
the
Brian
grant
was
getting
on.
Essentially
the
sit
calls
to
go
ahead
and
talk.
He
said
a
great
example
doing
it.
Clayton
does
a
good
job
as
well,
and
then
what
happens?
Is
you
know
on
the
private
side
yeah?
Maybe
you
have
to
take
a
few
deep
breaths.
B
I'm
gonna
I'm
gonna
shut
up
to
eric
tuned,
because
when
I
was
working
on
and
designing
scheduler
jobs
and
jobs,
it
was
eric
tune
that
I
learned
and
learned
a
lot
from
with
regards
to
internals
of
work
system.
Because
back
in
the
beginning,
we
always
peek
under
the
hood.
What
bor
actually
was
capable
of
from
the
document
that
was
published
some
years
ago
and
and
eric
was
a
person
with
always
got
a
great
expertise
and
knowledge
to
share
with
us
when,
when
building
the
batch
sub-system
super.
A
Nicely
all
to
shout
people
out
that's
great
now.
Next
question
has
to
do
with
what
on
one
second
I
just
wrote
it
down.
Oh
that's
what
they
meant.
Okay,
so
this
individual
sounds
like
their
current
reviewer
and
they
did
not
tell
me
what's
sake,
though
their
current
reviewer,
and
they
want
to
know
like
what
are
some
things
that
they
could
do
to
improve
their
skills
enough
to
essentially
be
a
maintainer
or
a
sub
project
owner.
A
C
C
The
approver
position
is
much
more
difficult,
so
to
be
an
approver,
it
needs
to
be
not
just
I've
made
a
few
contributions.
I
want
to
do
this.
The
role
is
not
aspirational,
so
you
have
to
already
essentially
be
doing
the
job
before
we're
going
to
be
adding
and
the
way
that
would
work
is.
When
you
get
reviews,
you
would
do
the
reviews
you
go
through.
B
Aspect
is
also
knowing
the
direction
of
the
project,
because,
like
David
mentioned
being
aware
of
the
fact
that
when
you
are
approving
a
piece
of
code,
you
can
actually
introduce
a
change
whether
that
will
be
a
breaking
change
or
a
non
breaking
change.
Whether
this
is
a
change
that
the
current
sig,
because
each
and
every
single
piece
of
code
is
owned
by
a
specific
sick.
Sometimes
it's
shared
between
several
SIG's
so
being
part
of
a
sig
and
understanding
the
direction.
The
sig
is
going
into
this
crucial
to
become
an
approver
I
would
say
it.
C
B
Is
very
important
because,
obviously
we
don't
you
as
an
approver,
don't
want
to
go
against
the
sig.
You
don't
want
to
introduce
tensions
and
sig
needings
are
available.
Our
online
everyone
can
join.
There's,
there's
usually
no
problems
voicing
out
their
concerns,
or
there
are
mailing
lists
for
every
single
special
interest
group.
You
can
always
raise
your
concerns,
whereas
the
topic
the
topics
can
get
discussed
several
times.
It
can
go
also
that
the
direction
might
change
over
the
course
of
discussion,
but
it
exists,
never
denied
also.
C
An
example
that
direction
would
be
something
like
where
six
Eli
is
trying
to
remove
every
reference
to
an
internal
type
inside
of
their
commands
and
if
any
one
of
the
approvers
messes
up
and
approves
a
poll
that
brings
in
a
dependency
on
these
types,
it's
sort
of
move
the
stick
backwards.
So
so
keeping
current
see
where
you
want
to
go.
That
is
an
important
block.
A
So
those
are
really
good
answers.
I
was
actually
taking
notes,
I
apologize
because
we
don't
really
talk
about
a
lot
of
this
stuff
in
documentation.
Right
I
mean.
Obviously
we
have
a
community
membership
guidelines
that
is
broad
enough
to
to
help
and
structure
it
enough
to
give
structure,
but
we
don't
necessarily
have
a
lot
of
those
who
documentation
and
people
might
not
work
at
Google
might
not
work
at
Red.
Hat
might
not.
A
The
last
time
I
checked
I
think
it
was
like
26,000
contributors
that
have
touched
in
some
fashion,
so
I
think
over
communication
in
isn't
necessarily
a
bad
thing.
So
I
really
appreciate
y'all's
question,
or
it
should
be
answers
to
that,
because
that
was
very
fruitful,
so
the
next
question
and
then
we're
actually
gonna.
C
Don't
know
that
we
see
so
many
in
API
machinery
I
see
a
lot
in
in
COI,
though,
and
and
when
I
see
when
I
see
it
going
into
other
areas.
The
pitfalls
that
I
generally
see
are
either
a
trying
to
bite
off
too
much.
If
you
submit
a
kept
saying,
I
want
to
change
some
big
piece
or
I
want
to
add
some
big
feature.
C
If
you
don't
have
a
track
record
of
of
contribution
and
and
really
if
you
don't
demonstrate
that
you're
actually
going
to
provide
the
the
code
contribution
itself
and
maintain
it,
drive-bys
are
really
hard
for
all
the
maintainer
--zz
we're
not
very
likely
to
approve
it,
and
so
some
people
get
frustrated
there,
they're
not
willing
to
start
out
very
small,
and
then
some
people
think
they're,
adding
something
small,
but
it
adds
significant
surface
area
and
if
you
say
I
want
to
add
a
new
command,
you
may
say
it's
isolated,
it's
just
one
command.
It's
it's
easy!
C
Let
me
let
me
do
this,
but
the
answer
quite
commonly
can
be
it's
it's
easy,
but
we
don't
know
if
you're
gonna
be
here
a
year
from
now
only
one
of
these
to
be
fixed,
so
start
small.
We've
brought
on
contributors
trying
to
do
things
like
snip
bad
tendencies.
We
don't
want
or
fix
factorizations,
to
use
current
libraries
right.
We
have
a
lot
of
history,
not
everything
uses
the
current
latest
and
greatest.
C
If
those
poles
aren't
super
interesting,
what's
a
great
place
to
start
right,
when
you
get
a
contributor
like
Yui
min
Kim,
Kim
min
in
API
machinery,
he
started
small
he's
fixed
dependencies.
He
went
through
the
admission
chain.
He
did
a
lot
of
work
that
built
upon
it
as
he
gained
familiarity
with
the
codebase
and
now
he's
off
working
on
a
new
cap
about
flow
control
for
API
machinery.
What's.
B
B
I'm
gonna
go
small,
like
literally
on
hats,
down
to
keyboard.
David
mentioned
high
level
details,
I'm
gonna
go
to
real
dirty
stuff,
like
all
the
new
contributors
expect
from
the
current
Cordy
warriors
unlimited
time
for
reviews,
which
is
a
problem
for
all
of
us.
We
have
only
a
limited
set
of
time
for
working
on
communities.
B
B
So
it's
sometimes
if
you're,
seeing
that
the
PR
is
not
being
really
viewed
again
and
again.
It's
not
a
problem
and
I
always
encourage
people
to
reach
out
for
to
me
on
slack,
because
github
modifications
are
with
this
size
of
the
projects
are
significantly
overwhelming.
So
I
always
tell
a
person,
please
reach
out
to
me
on
slack,
don't
be
offended
knock
at
my
door.
I
literally
helped
a
lot
of
people
where
they
were
every
single
day.
Reminding
me
please,
review
my
PR,
please
review
my
PR.
B
B
I
helped
another
person
take
several
stuff
in
the
coop
CDL
several
times
going
back
and
forth,
once
lack,
don't
be
afraid
to
reach
out
to
us
on
slack
and
ask
for
help
ask
for
reviews,
because
it
can
happen
that
we
just
lost
the
information
from
you
resubmitting
or
reapplying
additional
patches
to
your
poor
request.
So
if
you
don't
hear
from
us
for
a
couple
of
days,
just
get
in
to
slack
write
me
a
message:
I'll
be
more
than
half.
B
You
see
that
rather
than
people
not
seeing
a
review
for
me
for
a
couple
of
weeks,
and
they
got
they
just
either
forget
about
it
or
they
feel
not
welcome,
because
it's
it
I.
It's
not
my
intention
for
you
not
to
feel
welcome.
It's
just
that
I.
Don't
have
unlimited
amount
of
time
for
their
reviews.
So
that
is,
that
is
super
important.
Don't
be
afraid,
reach
out
and
slack,
we
don't
bite,
trust
me
or
your
ink.
You
can
find
us
I'll
be
more
than
happy
to
sit
down
with
you.
B
B
Do
that
well
actually,
there's
one
thing:
one
idea
that
I
want
to
talk
to
you
about
which
is
going
back
to
Pyke
on
after
the
main
conference.
What
PyCon
does
is
there's
four
days
of
Sprint's.
This
prints
are
there
for
people
to
sit
together
with
the
contributors
and
get
the
chance
to
actually
submit
the
code.
B
This
is
one
of
the
best
time
for
myself
at
least
and
I
know
that,
like
tons
of
other
people
to
enjoy
hike
on
because,
like
literally,
you
can
sit
next
to
one
of
the
core
developers
for
Python,
get
their
feedback
immediately
on
your
PR,
and
they
will
help
you
so
toward
as
one
of
the
last
session
during
hike
on
what
they
do.
Is
it's
not
only
Python
Python
related.
B
Actually,
a
group
of
people
will
stand
on
a
stage
and
say
I
will
be
sprinting
for
this
in
that
project,
and
you
will
find
me
in
this
in
this
room
and
there's
for
four
days.
You
can
sprint
with
them
only
the
hearts
work.
Folks,
actually,
sir,
there
stay
there
for
in
hire
four
days,
but
you
can
they'll
be
just
for
a
day
for
two.
B
As
long
as
you
want,
the
four-day
is
the
maximum
and
I
know
and
I've,
been
there
myself,
I'm
always
saying
there
for
four
days,
because,
like
literally,
this
is
the
only
time
that
you
can
get
to
know
those
people
you
can
actually
get
get
to
get
real
feedback
face
to
face.
It
is
so
much
better
than
you
know,
going
through
slack
or
other
medium
that
that
the
project
is
using
so
I
was
thinking.
Maybe
we
could
think
about
something
similar
for
cube.
Con
start.
A
A
A
C
B
Awesome
so
the
entry
point
for
cube,
CTL
command
is
like
literally
very
minimal.
It's
located
under
command,
keep
CTL
QCT
I'll
go
and,
as
you
look
through
the
code,
it's
like
literally
invoking
command
that
executes
with
some
flag
settings
and
I
always
should
the
only
reason
that
I'm
showing
you
this
is
because
when
you
are
debugging,
this
will
be
a
entry
point
that
you
need
to
point
those
two
from
then
on.
We
can
actually
jump
into
the
main
code,
which
is
located
under
package,
keep
CTL
command
command
go
here.
B
We
group
commands
into
several
into
several
groups.
There
are
basic
commands
such
as
Ron
said,
create
there
are
deploy
commands,
which
is
roll
out
scale,
auto
scale.
There's
a
group
of
classroom
management
commands
such
as
drain
top
class
or
info
there's
a
group
of
troubleshooting
and
debugging
commands
such
as
logs
eggs,
etc.
Then,
there's
also
the
advanced
commands
such
as
patch
convert
Dave
and
finally,
there
is
a
settings
commands
which
is
label
annotate
completion.
B
On
top
of
that,
there
are
other
commands
which
are
not
grouped,
but
here
is
the
main
point
where
we
actually
create
the
cube
CTL
binary
from
here
on.
We
will
be
diving
into
separate
command.
So
if
we
go
back
to
the
package,
cube
CTL
command
directory,
you'll
notice
that
every
single
command,
but
almost
but
I'll,
get
to
that
and
in
a
detail
in
a
bit
has
a
specific
directory.
B
So,
as
I
was
mentioning
annotate,
there's
annotate
directory
API
resources
is
one
of
those
commands
that
actually
has
to
one
of
the
directories
that
has
two
commands,
which
is
API
resources
and
API
versions,
but
in
general,
every
command
has
its
own
directory.
This
helps
every
single
person
to
figure
out
their
particular
command.
They
are
interested
in
and
they
can
literally
close
their
eyes
home
and
focus
only
on
this
specific
directory
when
they
are
trying
to
well
almost
but
we'll
get
to
that
in
a
bit.
B
B
Here's
the
file
they're
gonna,
see,
and
what
is
important
is
that
each
and
every
single
command
within
the
cube
CTL
will
follow
the
patterns
that
I
will
be
talking
about.
We
are
trying
to
enforce
the
patterns
as
of
couple
months
back.
So
if
you
see
commands
that
are
not
following
the
patterns,
you
are
more
than
welcome
to
open
APR,
where
you
will
be
bringing
commands
over
to
the
new
pattern,
and
the
pattern
is
as
follows:
good
first
contributor
match
exactly
so
each
and
every
single
command
will
have
a
command
name
optional
structure.
B
In
our
case,
this
is
annotate
option
structure.
This
structure
will
have
the
flags
that
the
user
can
provide
to
the
command
additional
helper
variables
that
are
needed
for
the
command
to
run,
and
the
most
important
pieces
is
the
I/o
streams
that
are
passed
over
to
every
single
command
and
this
particular
command
actually
has
also
record
slack
and
print
related
flags.
B
So
I'm
gonna
skip
the
description
and
examples
because
that's
not
important.
So
when
we
have
the
annotate
option
structure,
we
always
create
a
new
command
name:
option
structure,
which
will
always
accept
the
I/o
streams
and
is
responsible
for
filling
in
the
annotate
options
or
whatever
the
command
name
with
the
default
values.
Here
we
are
setting
the
print
fact
flags.
We
are
setting
the
records
flags
at
our
default
values
as
well
as
iostream.
B
On
top
of
that,
you
will
be
setting.
This
is
the
place
where
you
will
be
setting
the
default
values
for
your
flags
at
the
user.
Will
then
see
the
next
to
the
option.
Struct
constructor
there
will
be
always
a
constructor
for
the
method
and
if
you
recall
the
commands
and
go
that
I
was
talking
about
a
minute
ago,
you
probably
noticed
when
I
was
going
through
the
code
very
quickly,
that
there
was
an
invocation
annotate
that
new
command
annotate.
This
is
the
entry
point
for
each
and
every
single
command
in
cube
CTL.
B
B
Sample
usage
of
the
command
example
and
the
most
important
part,
which
is
the
run,
which
is
the
heart
of
the
command,
but
we'll
get
back
to
the
run
method
and
its
contents
in
a
bit
once
we
have
the
Cobra
command
structure
filled
in,
we
can
assign
the
flags.
Here
we
bind
the
record
and
the
print
flags
as
well
as
the
local
slacks
for
that
particular
command.
So
you
will
see
that
we
are
binding,
override
local
select
or
field
selector,
etc,
etc.
B
Flags
from
the
options
structure
that
we
created
a
minute
ago,
once
we're
done,
we
can
return
the
command,
which
is
then
being
constructed
through
the
Cobra
mechanism
into
the
final
execution.
Now,
let's
focus
on
the
run
because
the
run
is
is
also
crucial
and
in
the
majority
of
cases
the
run
execution
should
look
similar
across
all
of
the
commands
within
the
cube
CDL.
It
will
almost
always
contain
this.
Three,
oh
and
I'll
go
through
each
and
every
single
method,
so
that
you
know
what
is
important,
the
order
will
always
be
complete,
validate
and
run.
B
B
B
B
When
it
was
David
was
one
of
those
that
invented
I
will
go
with
this
pattern,
which
is
like
working
so
much
better
than
what
we
had
before.
So
aside
from
record
flags
and
printer
flags.
We
will
also
put
here
all
of
the
initial
vows
that
you
want
to
have
for
your
command,
such
as
reading
conflicts,
creating
your
clients,
parsing
additional
flags
and
whatnot
that
you
will
be
needing
for
further
comment
executions.
B
B
And
on
top
of
that,
it
also
allows
you
to
share
the
logic
for
specific
functionality,
such
as
the
printers
that
you
you've
seen
a
minute
ago
is
a
we
extracted
a
piece
of
code
which
currently
lives
inside
of
the
CL
at
runtime,
so
every
single
plug
in
other
four
keep
CTO
can
reuse
the
same
functionality
of
the
printers
for
printing
all
of
the
Q
built-in
resources,
as
well
as
the
CR.
These,
in
the
same
way
that
the
keeps
you
TL
does.
B
Similarly
for
a
record
you'll
find
flags
you'll
find
commands,
reusing
the
deletion
invocations
from
the
delete
method,
so
packaging
those
into
the
structures
allowed
us
also
to
reuse
some
piece
of
commands
more
or
less
in
other
comments
whenever
they
are
necessary.
So
that's
that's
also
a
great
win
for
for
no
duplication
within
the
cube,
CTO
codebase,
okay,
on
to
the
validate
method
in
that
case,
so
the
reason
for
validate
method
is,
as
you
might
expect,
is
to
validate
the
annotate.
B
Options
is
filled
in
based
on
your
needs
and
majority
of
cases,
but
none
limited
it
will.
It
will
only
validate
the
flex
that
the
user
can
provide.
So
in
this
particular
case,
we
are
validating
whether
all
n
selector
was
passed
together
because
that's
not
allowed
or
whether
new
annotation
that
remove
on
the
page
and
are
provided
and
are.
We
are
actually
validating
the
invitation
themselves,
whether
the
values
that
they
were
provided
are
our
valid.
B
So,
basically,
the
idea
is
to
ensure
that
the
annotate
options
strong
after
the
validate
invocation
is
valid
to
actually
run
the
command
itself
and
on
going
to
the
actual
run
command,
which
will
be
called
either
bran
or
run
command
name.
We
have
the
raw
logic
off
the
command,
which,
in
this
particular
case
is,
is
using
the
Builder,
which
is
a
a
very
handy
construct
that
we
created,
and
it's
also
living
inside,
of
the
CLI
runtime
for
retrieving
resources
either
from
a
file.
B
Once
we
have
those
values
and
after
several
error
checks,
we
use
the
visitor
pattern
to
go
through
all
the
resources
that
we've
read
in
the
previous
step
and
we
update
the
annotations,
so
you'll
see
update
annotation
several
times.
We
record
what
we
changed.
We
create
the
marriage
patches
and,
at
the
end
of
the
day,
we
either
replace
or
patch
the
resources,
and,
as
the
last
invocation,
we
have
the
printer
invocation
that
I,
David
and
I
were
talking
about
a
minute
ago.
B
So
each
and
every
single
command
has
that
structure
and
we're
we're
more
than
happy
to
accept
PRS
for
new
cut
from
new
contributors
which
are
turning
the
old
command
over
to
the
new
new
structure.
A
few
additional
tips
for
four
keeps
ETL
contributors
before
before.
We
are
all
closed,
always
next
to
the
command
within
the
same
directory,
which
is
in
our
case
annotate.
The
we'll
be
the
regular
tests
file
which
is
regular,
go
in
the
test
and
like
David,
was
mentioning.
B
The
tests
currently
are
much
better
to
write,
because
we
can
actually
focus
only
on
the
particular
parts
of
the
command
that
we
care
about
validating.
In
majority
cases.
The
complete
method
is
not
tested
because
it
is
responsible
for
creating
clients,
etc,
etc,
and
that
it's
not
required
to
be
tested
so
thoroughly
they
validate
and,
most
importantly,
the
run
method.
Are
that
the
ones
that
we
care
about
testing-
and
these
are
part
of
the
unit
tests
that
we
are
running
against
the
QC
deal
on
top
of
the
unit
tests.
B
Each
and
every
single
cube,
Cpl
command
also
has
a
set
of
Bosch
tests,
and
the
reason
for
the
batch
tests
is
I
think
it's
for
historical
reason
that
we
wanted
to
have
a
lightweight
version
of
testing,
because
the
last
step
for
testing
each
and
every
single
command
is
a
full-blown
cluster
being
set
up
and
we're
on
e
two
E's
that
I'll
be
talking
about
in
a
minute
e
2
e
stands
for
end-to-end
tests,
but
focusing
currently
on
the
Testament.
There
are
group
under
task
med
and
thanks
to
David.
B
B
Ron
Paul
test
why
it
is
important
to
know
the
name
of
this.
This
test
is
because,
when
you
are
invoking,
may
make
test
command
and
I'll
post
the
incantations
for
running
unit
tests
and
command
tests
after
I'm
done
talking
into
the
media,
our
contributors
slack
and
what
you
can
do
with
that
name
is
that
you
can
use
the
pod
only
to
pass
to
the
make
task.
Man
invocation,
and
only
this
particular
set
of
tests
will
be
run
instead
of
the
entire
test
command
suit,
which
is
lengthy.
B
It
can
go
up
to
40
or
even
hour,
so
I'll
post
the
oppose
the
incantation
later
on
s
and
finally,
like
I
mentioned
the
back
first,
the
only
downside
of
the
basses
is
that
they
are
not
running
against
a
full-blown
cluster,
but
they
are
running
against
a
simplified
API
KPI
server,
which
means
there
are
no
pots
actually
being
in
the
no
containers
running
the
code.
So
when
you
want
to
actually
verify
whether
the
cube
CTL
box
or
cube
CDL
exec
are
working
properly,
you
need
to
invoke
end
to
end
tests.
B
Sorry,
there
are
other
directories
cubes.
You
do
basically
spills
all
over
the
codebase,
and
that
is
also
true
for
e
two
E's,
but
the
majority
of
the
cube
CTL
tests
live
inside
of
the
test
e
to
e
cube
CTL,
and
these
are
run
against
a
full-blown
cluster
so
that
you
can
properly
verify
the
functionality.
You'll
notice,
probably
that
there's
a
port
fourth
separates
file,
which
is
testing
the
functionality
of
the
port,
fort
functionality.
B
I
think
with
that
I'm
gonna
close
and
if
you
want
to
hear
more,
will
be
actually
similar
codebase
their
enduring
sixty
light
intro
during
in
Cube
called
in
Barcelona,
so
feel
free
to
step
by
and
ask
some
more
questions.
I'll
be
more
than
happy
to
give
some
more
in-depth
knowledge
about
particular
pieces
of
code
or
at
the
same
time,
if
you
have
feedback
what
I
should
be
talking
more
and
what
less
I'll
be
more
than
happy
to
hear
about
it
as
well.
On
the
slack
our
Twitter
can.
A
A
Let's
see
nope,
we
got
everybody
all
right,
so
one
more
time,
I
want
to.
Thank
you
again
for
your
time.
Both
of
you
are
awesome,
George
as
well
George's
rvj
that
everybody
just
sees
as
George,
Castro
and
stream,
but
on
the
stream
right
now
making
sure
that
YouTube
is
acting.
Ok
and
everybody
can
hear
us
and
things
like
that,
thanks
to
Red
Hat
for
your
time
to
and
helping
the
upstream
community,
you
both
are
amazing
humans
and
I.
Look
forward
to
working
with
you
more
in
the
future.
All
right
ain't
y'all
appreciated
how.