►
Description
Operators Framework SIG Meeting July 20, 2018
Meeting Notes: https://gist.github.com/dmueller2001/502b1237f783e2062ed5c93b7d7174da
Guest Speakers:
Sebastien Pahl - Overview Operator Framework
Tom Bentley - Strimzi Operator
A
A
And
now
now
we
feel
like
we're
in
a
really
good
spot,
where
we've
felt
out
this
problem
space,
and
we
want
to
help
build
some
tools
for
other
folks
to
be
successful
with
operators.
This
is
things
like
you
know,
sdk,
tooling,
to
help
you
build
operators,
so
you're
not
doing
all
the
toil
that
you
have
to
do
to
communicate
with
the
kubernetes
api.
You
can,
you
know,
bring
your
business
logic
and
not
have
to
worry
about
that.
Of
course,
you
know
somebody
has
to
worry
about
that.
A
A
So
if
your
application
wants
database
or
Postgres
database
being
able
to
say
lean
on
the
existing
work
of
a
Postgres
operator-
or
you
know,
whatever
different
types
of
queues
and
caching
layers
I
think
will
make
a
really
vibrant
ecosystem.
And
then
you
know
we
can
all
realize
the
goal
of
having
these
cloud
like
services,
the
same
user
experience
that
you
would
get
from
an
Amazon
or
and
azured,
but
on
any
kubernetes
cluster,
and
that's
really
the
exciting
part
is
all
of
these
are
targeting
kubernetes
api.
A
And
so
you
can
run
this
on
prem,
on
beam
layer
on
those
cloud
providers
and
have
the
exact
same
experience
and
if
you're,
one
of
the
ISP
partners.
That
is
looking
to
be
an
operator,
for
example.
This
now
means
that
you
know
you
can
address
the
entire
kubernetes
market
without
having
to
you
know,
make
as
your
specific
product
choices
or
amazon
specific
product
choices,
which
is
really
important
too
so,
and
you
know
kind
of
in
the
spirit
of
open
source.
All
of
these,
you
know,
are
being
collaborated
on
with
a
number
of
folks,
including
everybody.
A
On
this
call.
The
word
is
really
excited
to
grow,
that
ecosystem
and
I
think
I
want
to
use
this
time
to
go
case.
What
some
of
y'all
are
doing
in
the
interesting
challenges
that
you're
hitting
as
well
as
a
lot
of
the
successes
that
you're
having
and
then
figure
out
where
we
take
this
framework
from
there
to
make
it
most
successful.
You
know
with
the
eye
towards
it
being
a
true
kubernetes,
targeted
thing.
A
lot
of
folks
would
kick
this
off.
A
Like
I
said
our
firm
red
hat
and
coral
s,
but
we
don't
want
it
to
remain
that
way.
We
want
it
to
be
a
true
community
and
we
think
this
is
really
important
for
bringing
the
future
of
kubernetes.
All
the
growth
of
the
kubernetes
community
is
going
to
happen
on
top
of
the
cluster.
You
know
the
the
foundation
is
really
important
and
it's
already
really
strong,
and
so
how
can
we
make
folks
successful
running
applications?
A
On
top
of
that,
and
you
know
if
you
are
running
a
business-
you
you're
thinking
about
starting
a
start-up,
maybe
around
your
operator,
we
want
your
your
company
to
be
successful.
On
top
of
this
platform.
I
think
that's
all
the
thoughts
I
had.
Thank
you
all
for
joining
us
today.
I'm
pretty
excited
about
where
we're
gonna
go
and
I
hope
you
enjoy
the
hour.
B
C
Perfect.
Thank
you
much
the
end,
though.
Let
me
share
my
screen
so
just
as
an
introduction,
I'm
Sebastian,
I
joined
Red
Hat,
not
so
long
ago
and
I'm,
basically
leading
the
operator
initiatives
from
the
engineering
side
and
I'd
like
to
present
a
little
presentation.
That's
going
to
overlap
with
a
tiny
bit
with
Rob
just
said,
but
mainly
I
want
to
show
where
to
get
started,
where
you
can
find
everything.
So
let
me
share
my
screen.
C
Can
you
see
my
screen
yep,
alright,
alright,
anybody
who
doesn't
see
something
that
I'm
saying
about
just
a
something
and
all
that
I
just
slowed
down
alright.
So
let's
get
started
I'll
keep
this
not
in
presentation
mode,
because
I
want
to
jump
to
websites
real
quickly.
So
quick
introduction
like
what
is
an
operator
and
what,
where
are
we
doing
here?
Rob
touched
a
bit
on
this
point.
C
Our
goal
here
is
to
build
applications
that
have
Grenadian
a
native
API,
and
what
that
means
is
we
want
to
take
complex
applications
like,
for
example,
Postgres
or
Kafka,
which
there's
going
to
be
a
good
talk
about
right
after
me,
and
we
want
to
take
all
their
logic
and
all
their
the
complex
knowledge
that
is
in
each
application,
and
they
put
it
into
a
program.
We
want
to
be
able
to
operate
it
automatically.
C
We
want
to
be
able
to
leverage
all
the
features
of
these
applications
that
have
to
do
with
upgrades
and
other
pieces,
and
we
want
to
do
it
behind
kubernetes
ap
is
why
behind
kubernetes
ap
is
because
that
way,
you
have
one
way
of
managing
all
your
applications.
It's
nice
to
build
a
single
docker
container,
where
you're
going
to
have
your
application
package
and
a
way
to
run
it
anywhere.
But
we
all
know
that
application
gets
much
more
complex
than
that
and
stay
require
multiple
containers,
and
then
they
require
operational
knowledge.
C
What
do
I
do
with
these
containers?
How
do
I
deploy
them,
and
that
is
specific
to
each
and
every
single
application?
There's
not
one
application
out
there,
or
at
least
there's
a
lot
there's
a
lot
of
different
applications.
It's
out
there
and
they're
all
have
their
own
quirks
their
own
operational
knowledge
there
and
it's.
It's
really
only
the
experts
of
these
applications
that
know
how
to
install
them
and
operate
them,
and
that's
not
even
talking
about
when
we
get
into
the
kubernetes
world.
C
And
you
can
build
these
operators
with
just
like.
In
the
end.
It's
a
kubernetes
controller
for
those
who
are
familiar
with
that
there's
a
loop
that
runs
and
you're
able
to
react
to
events,
and
then
you
basically
do
what
your
application
needs,
depending
on
the
event
that
came
or
you
can
use
tools
that
I'm
going
to
talk
about
now.
D
C
What
is
the
operator
framework?
The
operator
framework
is
for
now
it's
three
projects
that
kind
of
work
hand-in-hand
together.
The
first
one
would
be
the
SDK.
The
SDK
is:
how
do
you
build
that?
What
how
can
we
abstract
as
much
common
code
as
possible
between
all
these
operators,
because
if
everybody's
gonna
write
an
operator
for
their
application
as
much
as
there's
domain-specific
knowledge
on
these
applications?
There's
also
very
a
lot
of
similar
things.
C
I
like
to
use
the
example
of
TLS
right,
everybody
needs
to
deploy,
TLS
certificates
manage
to
TLS
certificates
and
also
be
able
to
rotate
TLS
certificates.
That
is
something
where,
as
like,
while
the
rotation
and
deployment
of
these
TLS
certificates
is
specific
to
every
single
app
the
common
codes
to
be
able
to
generate
those
certs
and
basically
use
a
single
one-liner
to
tell
it,
for
example,
in
kubernetes
deployments,
I
want
this.
To
now.
C
Have
a
TLS
or
in
front
of
it
that
can
be
abstracted
away
and
used
in
a
common
manner
across
multiple
applications,
and
so
it's
things
like
this
and
also
tools
for
upgrades
for
metrics
and
others
that
we
want
to
encode
into
the
operators
DK,
so
that
people
have
a
very
easy
time
to
build.
Operators,
I
hope
everybody's
following
me.
Until
now,
the
next
step,
once
you
have
an
operator,
is
well
an
operator
is
good,
but
that's
just
one
application
you
run
once
and
then
what?
If
you
have
multiple
versions
of
these
application
in
your
cluster?
C
What
if
you
want
to
upgrade
them?
What,
if
you
want
to
upgrade
multiple
at
a
time?
That's
where
the
lifecycle
management
sure
it
comes
in
in
and
I'll
talk
about
it
a
bit
more
later,
but
Rob
mention
it.
It's
about
it's
a
problem
that
people
don't
know
they
already
have
it's
it's
basically
the
next
step
and
then
metering.
Another
thing
that
building
things
with
an
operator
will
it
can
help.
C
How
do
I
know
how
much
this
single
database
table
or
even
row
costs
course
that
requires
quite
a
bit
of
logic,
to
write
into
the
SDK
into
the
operator,
but
that
logic
can
then
be
aggregated
through
the
operator
meeting
framework
and
a
metering
tool
toolkit,
so
I'm
gonna
rego
a
go
again
on
multiple
on
multiple
on
all
of
these
through
their
each
of
their
websites.
There's
a
question
I'm
just
gonna
check.
If
it's
a
question
we'll
answer
that
later.
C
C
One
thing
you
have
list
of
operators
and
I
want
to
also
go
and
each
project
individually.
So
if
you
go,
for
example,
to
the
SDK,
you
can
see
that
this
is
that's
the
project.
That's
where
you
get.
You
can
start
it,
and
it's
I
want
to
talk
a
bit
about
how
easy
it
is
to
basically
get
started
if
you've,
if
you're
familiar
with
something
like
and
not
everybody
likes
it,
but
it's
a
good
analogy:
Ruby
and
rails.
When
you
do
Ruby
and
rails,
you
don't
have
to
know
the
intricacies
of
HTTP,
you
don't
need.
C
You
know
the
intricacies
of
a
post
press
at
first
and
you
can
get
started
by
basically
using
models.
Views
controllers
and
you
can
also
generate
quite
a
bit
of
code
and
you
get
a
lot
of
utilities
with
that
code,
that's
the
operators.
Dk
tries
to
do,
but
for
the
kubernetes
world,
though,
I'm
showcasing
like
the
getting
started,
because
it
shows
quite
easily
that
you,
basically
you
generates
your
application
and
then
you're
able
to
to
build
it.
C
You
built
you
put
in
your
your
your
domain-specific
code,
which
was
happen
here,
which
is
a
much
longer
process
than
this
shows,
of
course,
and
then
once
you're
happy
you're
able
to
build
push
it
just
like
any
container
and
then
deploy
it,
and
here
it
shows
a
deployment
by
hands
because
we
don't
have
a
lifecycle
manager
yet,
but
that
the
that's
just
an
example.
So
I
encourage
you
to
come
here,
there's
they're,
just
quite
enough
stuff
to
have
a
look
at
this
is
just
the
getting
started
guide.
C
You
also
have
that
we
have
quite
a
bit
of
documentation
to
user
guide
and
more
interesting
if
you're
interested
in
knowing
how
you
build
your
first
operator,
we've
put
in
an
example
to
show
how
you
can
build
a
vault
operator
with
this
SDK
and
to
go
a
bit
more
in
in
like
technical
terms,
because
I
like
to
do
it
to
explain
that
here.
This
is
the
basic
structure
of
a
an
operator.
C
It
has
multiple
multiple
like
it
has
all
the
go
dependencies
and
everything,
and
then
you
would
put
your
logic
into
one
place,
which
is,
for
example,
here
of
and
you're
basically
writes
a
handler.
This
one
is
a
very
simple
handler.
That's
now
calling
other
other
piece
of
the
codes,
but
the
basics
of
an
operator
is
really
shown
well
here,
which
is
you
have
a
loop.
You
receive
events
from
the
kubernetes
api
and
then
you
basically
work
on
those
events
to
to
do
what
you
need
for
your
application.
C
D
C
Step
is
basically
the
operator
lifecycle
manager.
That's
the
next
place.
I
encourage
you
to
have
a
look
at
the
this
repository
is
quite
simple
to
use.
It
also
has
the
same
getting
started
guide
as
everything
you
don't
need
to
it
works,
and
it
will
eventually
be
included
and
OpenShift,
but
you
can
install
this
on
every
single
kubernetes
cluster,
and
that
is
a
an
important
distinction,
because
if
you
imagine,
you
have
to
use
different
variety
of
uber,
Navy
styles,
it
doesn't
matter
as
long
as
the
zipa
Jubran,
a
DS,
compatible
cluster.
C
You
can
install
that
lifecycle
manager.
Now
what
you
get
out
of
this
lifecycle
manager
is
basically
a
repository
of
applications
where
you
can
then
decide
I
deploy
these
applications
in
a
multi-tenant
fashion.
That's
the
that's
one
of
these
goals
you,
but
the
lifecycle
manager
is
aware
of
the
burn,
ADEs
namespaces.
It's
able
to
tell
do
it
and
it
also
does
one
other
important
thing.
It
manages
the
CR
DS
so
that
users
don't
have
to
install
them
themselves.
They
don't
have
the
permissions
to
do
that.
C
C
The
last
part
I'd
like
to
highlight
is:
we've
made
a
list
of
operators.
Not
everything
here
uses
the
operators
decay,
but
if
you've
built
an
operator,
I
would
encourage
you
to
contribute
it
here
to
highlight
it,
and
basically
this
this
repository
is
probably
going
to
get
curated
more
and
more.
We're
gonna
show
show
off
what's
built
with
the
operators,
decay.
C
What's
not
what
can
be
used,
but
right
now
it's
basically
a
list
of
many
things,
but
you
can
see
that
already
a
lot
of
people
have
like
it's
the
operator
concept
and
started
building,
what's
called
an
operator
or
their
specific
platform.
I
don't
want
to
vouch
for
the
quality
of
each
of
these,
since
they
are
not
like
going
through
any
certification
process
whatsoever,
and
that's
where,
where
all
of
the
operator
framework
also
comes
in,
our
goals
is
not
just
to
help.
You
build
these
operators,
but
eventually
our
goal
is
to
help
you
test.
C
These
operators
make
sure
that
they
work
that
it
behave
well
in
a
lot
of
environments.
So
we
want
to
build
a
through
the
sdk,
a
common
way
to
test
them
and
to
certify
them
on
the
platform
like
openshift,
that
is,
that
is,
what's
going
to
transform
a
list
like
this,
which
you've
all
seen
in
the
past
for
various
applications
containers
and
basically
no.
Yes,
this
that's
that's
a
list.
That's
I
still
have
to
do
my
own
research,
but
with
once
we're
a
bit
further
down
the
road
with
our
testing
kits
you'll
be
able
to
know.
C
C
So
that's
a
quick
intro
through
all
of
that
and
then
the
last
thing
I
would
say,
take
a
look
at
our
getting
started
guide,
it's
much
more
in-depth
than
the
just
the
one
on
the
operator
SDK
that
I
showed
off
here.
It
is
an
end-to-end
test
with
operator
SDK
and
the
lifecycle
manager
we'll
throw
in
the
metering
in
it
eventually,
but
this
will
a
label
to
to
do
everything
that
I
said
dry
out
everything
and
what
I
said
in
a
single
kubernetes
cluster
quite
easily
like
just
follow
this,
and
everything
will
become
much
clearer.
C
The
last
things
I
would
like
to
add:
are
we
created
a
channel
to
talk
all
things
operator
on
the
kubernetes
lac
and
we
also
have
a
Google
Group.
These
links
will
be
shared
by
day
in
after
the
for
everybody
who
wants
to
join.
So
that's
it.
That
is
the
main
thing
that
I
wanted
to
do
and
what
I
wanted
to
highlight.
We
can
show
and
showing
you
what's,
each
and
every
one
of
these
components
are
all.
B
There
are
a
couple
of
questions
and
some
of
them
have
been
answered
in
the
QA
and
chat,
but
I
think
if
we
go
back
to
Alexander
at
last
question
and
I
can
unmute
people
that's
two
as
well,
so
it
examine
there
wants
to
follow
up
on
that,
find
you
sure,
and
you
are
you
have
a
mutant
for
yourself.
Alexander.
E
C
So
I'll
take
that
when
the
hour,
the
goal
of
our
framework
is
to
go
through
series
like,
of
course,
you
can
write,
cooperate
like
if
we
forget
about
the
framework
for
a
second,
you
can
write
a
kubernetes
controllers
that
does
all
this
right.
That
listens
just
to
specific
things,
and
also
the
operator
framework
itself
is
also
capable
with
the
SDK
of
listening
to
specific
objects.
C
But
what
we're
trying
to
do
here
is
kind
of
an
opinionated
pattern
where
we
drive
things
through
CR
DS,
because
it
allows
us
to
like
you
need
to
put
that
API
somewhere
and
if,
if
all,
if
all
your
controller
basically
is
doing,
is
like
doing
some
ingress
work
or
let's
say
watching
a
couple
of
stateful
sets
with
and
doesn't
need
to
be,
basically
influenced
through
a
CR
D.
Then
it's
not
necessarily
the
you.
Don't
necessarily
need
to
use
something
like
the
SDK
which,
but
you
can
still
call
it
kind
of
an
operator.
C
F
C
A
You
know,
you've
you've
tested
out
this
Postgres
operator,
but
you're
running,
you
know,
say
30
copies
of
it
and
every
team
is
running
databases
operator
and
then
till
you
have
a
node
failure
or
you
have
a
networking
blip
or
one
of
your
AC's
goes
out.
If
that
Postgres
operator
is
instrumented
to
start
emitting
metrics
about
when
it's
doing
failover
or
when
it's
shards
or
whatever
kind
of
underlying
storage
is
not
available,
you
can
start
to
get
a
sense
of
like
how
these
things
impact
the
actual
applications.
A
If
folks
are
running
without
having
to
go
to
around
to
every
team
and
say
hey,
did
this
impact,
you
did
you
have
downtime
whatever
and
you're,
getting
like
the
actual
application
level
metrics
from
Postgres
itself
or
from
this
operator,
so
that
it's
really
like
not
just
generic
white
box,
like
oh,
the
network
request
went
down
or
like
oh,
it's
now,
using
less
ram
or
whatever,
which
is
useful
information.
It's
that
you're
getting
a
very
specific
thing.
A
So
another
example
say
you
were
running
like
a
very
large
cloth,
cluster
or
SEF
cluster
that
if
you
have
to
do
heels
on
some
of
that
underlying
stuff,
as
things
are
getting
replicated
round,
knowing
how
many
of
those
happen
per
hour
or
per
week
or
whatever,
and
correlating
that
to
cluster
events
can
be
really
really
useful
for
you
to
help
either
make
your
operator
more
efficient.
So
it's!
Why
is
this
thing
healing
so
much?
A
B
G
The
ones
I
like
and
I
want
I
wondered
if
I
would
have
I
would
I
would
be
able
to
make
this
metric
system
get
a
domain
knowledge
of
my
operators.
So
let's
say
I
have
a
program
and
there
I
want
to
charge
by
users,
so
would
I
be
able
to
clock
easily
the
domain
knowledge
of
my
of
my
application
into
this
operator
matrix.
A
Yes,
100%
those
types
of
metered
billing
type
use
cases
are
perfect
for
this
framework
and
that's
one
of
the
exciting
things
that
you
know
there's
like
a
set
of
operational
things,
but
then
also
a
set
of
business
things
that
you
can
get
unlocked
by
using
this
and
so
yeah.
What
you
would
do
is
in
the
SDK
we're
gonna
build
some
functionality
where
you
can
say,
I
want
to
emit
this
metric,
but
I'm
already
tracking
and
then
it'll
get
scraped
by
the
metering
system
and
then
aggregated
and.
C
F
Selected
that,
yes,
these
metering,
though
the
actual
getting
that
data
is
only
the
1/2
and
so
like
the
metering
component,
offers
api's
and
long
term
we're
gonna,
probably
build
in
default
exporters
that
can
basically,
on
top
of
the
existing
reporting
functionality.
Is
that
you
already
get
it.
You
can
query
the
the
results
out
of
the
api's,
and
so
then
the
the
next
piece
would
be
to
for
us
to
make
it
easy
for
you
to
get
that
kind
of
data
out.
C
C
Then
you
can
use
kind
of
very
easily
once
you
have
the
lifecycle
manager
installed
and
that
kind
of
gives
you
it
gives
your
app
quite
a
bit
of
ways
of
using
helm,
charts
with
operators
and
you're
able
to
use
then
the
helm
without
tiller,
you're
able
to
use
helm
without
having
too
many
privileges,
which
is
something
that
is
quite
useful.
It's
about
how
vs
operators
I'll
let
Rama
for
bits,
but
it's
like
if
they
complement
each
other
right
like
the
helm.
Laps
are
simpler.
A
Yeah
and
if
you
think
about
it
this
way,
helm
is
really
good
for
running
these
stateless
applications.
But
it's
kicked
off
with
like
the
helm,
CLI
or
you
know
it's
like
you
know,
a
human
is
in
the
loop
there,
and
so
one
of
the
exciting
things
about
the
operator
is
you're,
taking
that
human
out
of
the
loop
and
then
you're,
making
it
kubernetes
native,
so
you're
not
I'm
having
to
ride
against
a
helmed
API
you're,
just
using
a
CR
D
and
the
way
our
helm
operator
kit,
I
linked
it
in
the
chat
works.
A
A
If
you
want
to
add
more
stapl
kind
of
stuff
to
your
application,
then
what
you
can
do
is
move
it
over
to
I'll
say,
like
a
real
crew
operator,
a
go
code
operator
and
do
the
same
thing
model
those
things
and
start
building
in
your
staple
logic.
And
so
that's
where
we
think
the
helm
operator
kit
is
really
nice.
If
you
started
with
an
operator
and
then
you
can
kind
of
decide
how
much
further
you
need
to
take
it.
F
I
know
I
can
tell
you
confidently.
This
works
because
I
don't
use
that
actual
helm
operator
kit.
We
developed
on
the
metering
project,
but
I
use
a
precursor
to
that.
That
is
a
home
operator
and
90%
of
opponents
in
metering
are
deployed
using
a
helm
operator
stack
and
only,
and
then
that
operator
is
actually
what
employs
the
bespoke
cooperator.
That
does
all
the
specific
metering
stuff
as
well.
F
Basically
right,
though,
there's
a
good
place
to
be
able
to
use
both
systems
and
just
a
shout-out
to
people
are
working
on
an
ansible
operator
as
well
like
a
similar
kind
of
bridge
for
people
who
have
playbooks
to
be
able
to
interact
with
kubernetes
through
a
playbook
with
the
kubernetes
modules
enhance
bolt
and
then
the
CR
is
kind
of
the
edge
trigger
for
your
hands,
will
playbook
and
its
inputs.
So
that's
also
coming
up
in
the
next
couple
months:
Thanks.
B
Hey
guys
in
the
interest
of
time,
because
I've
asked
Tom
dentling
to
give
a
little
talk
topic
to
on
stream.
Z
we're
gonna
pause,
the
queue,
a
stave,
all
those
questions
and
because
there's
a
couple
of
them
that
are
good
ones
to
more,
logistically
inclined.
But
if
Tom
was
going
to
give
us
a
little
talk
on
strem
Z,
which
might
release
say
some
of
these
topics
as
well.
If
that's
okay,
shall
we
let
Tom
share
his
screen
and
kick
off
his
his
talk
as
well
and
Sebastian?
D
Presentation,
oh
there,
we
go
okay,
so
I'm
gonna
be
talking
a
little
bit
about
rimsey,
which
is
about
running
Apache
Kafka
on
kubernetes
and
openshift,
though,
if
anyone
doesn't
know
what
actually
Kafka
is
it's
basically
a
highly
scalable
messaging
system?
It's
come
out
of
LinkedIn
quite
a
few
years
ago
now
and
it's
obviously
being
a
messaging
system.
D
It
is
quite
stateful
and
for
that
reason
it's
something
which
is
quite
well
suited
to
using
operators.
So
the
scrim
seed
project
is
about
making
that
as
simple
as
possible,
so
that
you
can
just
use
Kafka
in
coop.
Yetis
no
can
shift
without
having
to
necessarily
know
all
the
operational
details,
so
obviously
the
operators
that
have
been
fed
some
of
that
logic,
so
we've
actually
got
two
operators
in
string
Z.
At
the
moment,
we've
got
the
first
one
is
called
the
cluster
operator
and
what
that
does?
D
So
the
manage
resources
that
the
sort
of
operator
is
responsible
for
are
a
stateful
set
each
for
zookeeper
and
Kafka,
and
then
we've
got
some
services
in
order
for
the
clusters,
the
zookeeper
cluster
and
the
catholic
lustre
to
communicate
amongst
themselves
and
also
to
provide
client
access
to
the
Kafka
cluster
and
for
Kafka
to
access
zookeeper.
We
need
persistent
volume
claims
because,
as
I
said,
these
things
are
stateful,
though
in
particular
for
a
zookeeper.
D
It's
important
that
if
a
pod
gets
restarted,
it
has
access
to
the
same
data
that
it
had
before,
because
it
won't
be
able
to
recover
that
from
the
rest
of
the
zookeeper
nodes
in
the
zookeeper
cluster
for
Kafka.
It's
not
quite
that
bad,
because
kefka's
built-in
replication
is
able
to
recover,
but
it
can
take
quite
a
long
time.
So
it's
worthwhile
using
a
persistent
volume
claim
in
order
to
minimize
the
amount
of
time
it
spends
fetching
information
from
the
the
rest
of
the
cluster.
D
So
you
could
me
that's
all
right:
okay,
so
I'll
just
well
I
suspect
people
probably
been
following
on
so
I'll
just
carry
on.
So
the
the
other
operator
we've
got
is
what
we
call
the
topic
operator.
So
once
you've
got
this
caf-co
cluster
running
inside
kubernetes.
The
next
thing
you
want
to
obviously
do
as
a
user
is
you're
going
to
start
using
it,
and
you
will
want
to
be
able
to
deploy
your
kafka
applications
inside
kubernetes
in
order
to
use
it
and
it
was
kind
of
nice.
D
If,
as
part
of
that
same
deployment,
you
can
have
a
customers
or
representing
a
topic
within
Kafka,
so
that
you
can
deploy
your
topic
and
configure
it
at
the
same
time
as
you're
deploying
the
rest
of
your
application
without
having
to
have
sort
of
extra
manual
steps
or
extra
scripting
in
order
to
set
up
the
topics
that
your
application
needs.
So
that's
the
sort
of
the
rationale
behind
the
cluster
operator,
and
this
is
all
sort
of
well
and
good,
but
there's
a
bit
of
a
problem
which
I'll
get
onto
in
a
minute.
D
Hang
on
I'll
just
talk
about
this
slide
first,
so
this
is
what
our
custom
resource
looks
like.
We
started
off
using
config
Maps,
actually
to
represent
the
topics,
sort
of
identifying
them
with
a
label
so
that
we
knew
which
config
maps
represented
caf-co
topics,
and
this
is
now
the
sort
of
a
customer
source
direction
which
we're
now
going
in
which
I've
been
working
on
this
last
week.
D
So,
as
you
can
see,
topic
is
sort
of
a
relatively
simple
thing,
whereas
go
got
built
in
partitioning,
so
we
have
to
say
the
number
of
parts
in
our
topic
and
we
also
get
to
say
the
number
of
replicas
in
our
topic
and
there's
a
bunch
of
different
configuration
options.
So
there's
about
a
dozen
or
so
different
topic,
configs
that
you
can
set
there.
D
So
that's
what
a
the
topics
customers
also
looks
like,
but
the
problem
that
we've
got
is
that
in
Kafka
there's
an
API
for
creating
topics,
applications
can
create
topics
and
so
and
also
there's,
depending
on
how
the
broker
is
configured.
If
you
try
and
consume
from
or
produced
to
a
topic
that
doesn't
exist,
it
will
get
created
automatically.
D
So
we
wanted
to
make
this
the
synchronization
work
properly,
which
meant
that
we
would
have
to
create
topics
when
topics
were
created
in
in
caf-co,
we'd
have
to
create
an
include
vanetti,
so
OpenShift.
So
we
ended
up
having
to
contemplate
having
a
topic
operator
that
would
synchronize
the
topic
information
in
both
directions.
So
we
bidirectional,
in
other
words,.
D
If
it's
going
to
be
by
direction,
we
have
to
consider
what's
going
to
happen
if
the
two
ends
changed
the
same
topic
at
the
same
time.
So
on
the
left.
Here,
we've
got
a
topic
as
it
might
exist
as
a
customer
source
inside
kubernetes,
and
someone
might
change
something
there
and
at
the
same
time,
and
they
might
get
changed
on
the
kafka
side
and
we
don't
want
the
state
to
get
all
out
of
kilter
and
end
up
with
a
mess
where
the
cab,
the
resource
in
kubernetes,
doesn't
accurately
reflect
the
topic
in
Kafka.
D
So
you
might
think
that
the
chance
of
that
pretty
small,
but
the
window
is
probably
bigger
than
you
at
first
realized,
because
we've
got
to
consider
that
the
topic
operator
might
know
always
be
running
if
it
crashes
and
restarts,
then
the
window
will
be
as
big
as
the
the
time
that
it's
down
and
if
it
gets
under
ployed
and
then
later
redeployed,
then
again
the
window
could
be
quite
a
lot
bigger.
So
to
do
it
properly.
We've
got
to
deal
with
this.
D
This
inconvenient
fact
that
both
ends
can
change
at
the
same
time,
if
you
think
about
it.
If
the
operator
starts
up
and
it
sees
the
state
on
the
left
and
the
state
on
the
right
here,
it
can't
tell
what's
changed:
it
doesn't
see
the
things
which
I've
highlighted
in
bold.
It
just
sees,
you
know
some
set
of
properties
and
some
other
set
of
properties
in
it
can't
tell
which
end
has
changed,
since
it
last
tried
to
reconcile
so
to
solve
that
we
use
a
three-way
diff.
D
Basically,
we
have
a
our
own
copy
of
the
topic
state,
which
we
treat
is
the
source
of
truth,
and
whenever
we
reconcile
the
custom
resource,
we
compare
it
with
that
private
copy
that
private
state,
and
likewise,
when
we're
looking
at
the
topic
in
caf-co,
we
compare
it
with
our
private
state
and
from
that
we
can
can
figure
out
sort
of
how
that
end
has
changed.
So
how
the
kubernetes
resources
change
or
the
Kafka
topic,
and
then
we
can
check
first
of
all,
but
they've
not
changed
in
compatibly
in
the
same
place.
D
So
if
the
number
of
partitions,
for
instance,
has
been
increased
to
a
different
number
on
each
side,
then
obviously
that's
an
incompatible
change,
and
in
order
to
deal
with
that,
we
have
to
apply
some
sort
of
policy
over
which
side
should
be
the
winner.
But
if
those
two
differences
are
not
are
disjoint,
so
they
have
an
empty
intersection,
then
we
can
construct
the
union
of
those
two
differences
and
apply
that
both
sides
and
that
will
reconcile
the
changes
which
happened
at
both
sides.
So
in
this
case
the
union
looks
like
this.
D
Another
of
politicians
is
changed
18
and
this
conflict
property
has
changed
that
and
in
that
way
both
sides
end
up
having
the
same
state.
So
this
is
not
the
normal
way
operator.
An
operator
is
normally
sort
of
first
thing
to
say
really
is
that
you
only
want
to
make
your
operator
bi-directional
if
you
absolutely
have
to,
because
it
does
increase
the
logic
rather
a
lot,
and
obviously
the
simple
your
operator
is
the
the
more
likely
it
is
to
actually
work
properly.
D
Another
consequence
of
this
is
it
makes
the
operator
stateful,
whereas
a
normal
unidirectional
operator
is
pretty
much
stateless.
It's
just
consuming
the
resource
on
the
kubernetes
side
and
then
trying
to
make
other
resources
match
that
so
with
it
being
stateful,
we
have
to
worry
about
the
availability
of
that
persistent
state,
so
for
us
it
may
tend
to
use
zookeeper
because
it's
required
by
a
factory
Kafka
anyway,
and
therefore,
if
a
zookeeper
is
not
available,
we
wouldn't
be
able
to
reconcile
the
topic.
D
But
if
you
were
having
to
contemplate
something
like
this
yourself,
then
you
would
have
to
have
some
highly
available
persistent
store
available
to
you
to
be
able
to
do
that
properly.
And
finally,
this
the
middle
bullet
point
here
is
you
always
want
to
make
sure
that
you
update
your
private
store
of
date
last
so
that
if
your
operator
happened
to
crash
before
that
gets
updated,
but
you've
updated
one
or
the
other
side,
then,
when
your
operator
restarts
it
would
correctly
synchronize
this
to
date.
D
Again,
though,
that's
the
end
of
the
slides
I'm
hoping
to
do
a
demo
as
well.
Now,
though,
I've
already
got
the
cluster
operator
is
up
and
running,
so
you
can
see,
we've
got
a
bunch
of
different
pods
going
on
there.
So
we've
got
the
cluster
operator
itself
at
the
bottom
here,
and
we've
got
a
cluster
of
three
zookeeper
nodes
and
three
Kefka
nodes
and
I've
also
got
a.
D
So
in
the
slides,
I've
shown
you
the
the
customer
resource
version
of
the
topic
that
I've
been
working
on
this
week.
Unfortunately,
I
was
hoping
to
get
that,
although
I
was
hoping
to
get
that
working
for
this
demo
I've.
Not
quite
it's
been
able
to
get
it
working
time,
though
I'm
going
to
be
showing
you
a
version
that
it's
based
using
config
maps
to
represent
the
the
topic,
though
you
can
see
here.
D
D
They've
got
the
five
and
the
number
of
bytes
in
the
segment
ends
in
seven
here
and
their
different
ends
and
with
30
and
o2.
So
what
I've
done
is
I've
prepared
it
ready
so
that
both
ends
are
slightly
different
and
the
topic
operators
we
saw
when
I
got
the
pods
isn't
running
yet
so
I'll
now
start
the
topic
operator
and
hopefully
we'll
see
that
both
sides
match
up
so
just
so
that
you
know.
So
it
was
the
this
one
which
change
on
the
Kafka
side.
D
D
D
See
it
yeah,
so
it's
started
up
there,
but
it's
not
yet
not
yet
ready,
wait
for
that
come
now.
Hopefully,
I
can
get
the
one
side
which
is
showing
the
five
and
get
the
other
and
the
yellow
which
is
showing
ending
in
30.
So
it's
reconciled
both
ends
when
it
started
up
so
I
think
that's
pretty
much
all
I've
got
to
show
you.
Has
anyone
got
any
questions?
I.
H
D
D
D
I
mean
certainly
in
the
in
the
cluster
operator.
We
use
a
locking
strategy
so
that
we
only
processing
the
cluster
sort
of
you
know
with
one
thread
at
any
one
time.
Basically,
so,
although
you
can
have
multiple
clusters
all
sort
of
being
reconciled
simultaneously,
there's
only
one
which
is
being
operated
on
sorry,
although
you
can
have
multiple
being
reconciled
simultaneously,
there's
only
one
thread
which
is
operating
on
in
particular
cluster,
though
yeah,
okay,.
D
G
A
Have
a
need
and
an
operator,
or
can
you
think
of
a
situation
where
you
want
to
have
this
kind
of
bi-directional
traffic
moving
where
you
know
you're
gonna
use
some
like
the
kubernetes
api
is
a
creative
CRD
that
might
drive
something
in
the
operator,
but
then
also
have
to
consume
things.
That
would
create
resources
of
that
same
type
from
a
different
API.
I
I
I
want
to
allow
the
developers
to
define
which,
which
realms
and
users
and
clients
they
want
to
consume
in
their
application
and
have
the
operator
set
those
up
and
drop
them
into
secrets
or
that
for
that
use
for
that
user
to
consume,
and
so
they
could
potentially
log
into
that
key
cloak
and
change
something
about
one
of
those
things
that
can
would
mean
that
the
people
would
be
able
to
sing,
for
instance.
So
that's
probably
another
situation
where
you
could
have
this
two-way
sing.
I
D
Yeah,
if
you
are
in
the
position
to
say
that
you
know
the
kubernetes
is
the
way
and
the
only
way
to
do
it,
then
that's
definitely
the
way
to
go
much
easier
to
have
a
policy
like
that.
We
couldn't
because
of
Africa
streams,
for
instance.
The
way
it
creates
topics
dynamically
just
meant
that
we
can't
turn
around
to
people
and
say:
oh
well,
you
shouldn't
be
using
Africa
streams
because
that's
you
know
one
of
the
main
sort
of
selling
points
of
Kafka
so
yeah.
We
felt
that
we
couldn't
really
take
that
approach.
A
E
A
The
previous
question
of
just
when
you
can
use
kubernetes
is
your
data
source
of
truth.
Then
you
get
all
the
atomic
operations
that
you
get
from
the
kubernetes
api,
which
really
you
know
where
the
etsy
primitives
that
are
being
pulled
through.
You
can
do
like
those
compare
and
swaps
and,
like
you
know,
only
have
one
person
operating
on
an
object
at
a
time
which
is
pretty
nice
I.
F
F
F
If
I,
this
is
based
on
the
topic
in
the
SDK
mailing
list
that
we
had,
which
is
if
your
resource
gives
me
as
if
it
exposes
a
secret
for
connecting
to
it,
for
example,
and
a
URL
or
whatever
it
needs
to
talk
to
it.
Maybe
it's
just
the
name
of
service
and
the
port,
then
what
would
be
really
exciting
for
me
is
being
able
to
actually
just
prototype
using
your
coffee
operator
with
my
my
metering
operator
and
so
I
just
want
to
know
like
what
kind
of
support
there
would
be
for
that.
If
any
yeah.
D
It's
nothing
that's
on
the
immediate
roadmap,
but
we
do
want
to
add
support
for
several
dub
resources
in
our
CRD,
eventually
so
you'll
be
able
to
scale
the
catechol
cluster
using
the
cube
cuttle
command
to
scale
it
and
stuff
like
that,
and
likewise
have
states
information
so
that
you
can
easily
consume
the
endpoint
from
other
things.
I
think
that's
what
you're
asking
about
yeah.
D
D
No,
we
definitely
want
to
get
I
mean
that's
sort
of
one
of
the
benefits
having
the
resource
is,
it
makes
it
all
sort
of
much
more
kubernetes
native,
and
then
you
know
obviously
sort
of
other
software,
such
as
your
own,
is
able
to
consume
these
resources
as
well
and
discover
them,
though
yeah
that's.
Definitely
one
of
the
benefits
of
this
approach.
B
A
Can
take
this
one
as
Ted
said
in
the
chat
we're
really
starting
with
go
because
it's
currently
the
easiest
to
get
up
and
going
because
of
all
the
client
generation
and
stuff
that
kubernetes
has
built
into
it.
But
of
course
Java
is
probably
the
next
language
that
would
make
sense
to
go
into
just
because
it's
widely
adopted
in
a
lot
of
enterprises,
a
lot
of
software's
already
using
it,
and
so
especially
when
you're
trying
to
talk
to
you
know
other
api's
that
are
have
a
Java
interface,
for
example,
is
really
useful.
A
D
C
Yeah
absolutely
and
we're
kind
of
a
bit
of
in
conflict
between
on
one
side,
we
have
to
go
over,
that's
like
the
lingua
franca
grenade
ease
and
this
world,
and
then
Java
the
Frank
of
the
enterprise
and
we're
trying
to
marry
that
in,
like
eventually
we'll
get
there
right
like
this
is
something
that
we
want
to
do
we're
very
aware
of
it.
It's
just
this
is
how
we
get
started
a.
J
F
In
the
Java,
if
you're
gonna
write
anything
that
talks
to
zookeeper
there's
pretty
much
seed,
you
can't
you
should
use
anything
other
than
Java
for
reasons
that
most
zookeeper
clients
have
bugs
that
break
everything,
usually
when
it's
not
written
in
Java.
So
that's
like
where
I've
seen
most
of
that
come
from
myself.
B
There
was
a
question
earlier:
I
apologize,
I,
dropped
out
for
two
seconds
and
lost
all
the
chat
so
Rob.
If
you
can
cut
and
paste
it
and
throw
it
into
the
notes
section
of
the
gist
I
think
you
can
add
a
comment
to
the
gist
and
then
I
can
put
it
in.
But
then
earlier
question
was
something
around
the
up:
creating
a
community
hub
for
operators
and
that's
something
that's
bandied
about
a
little
bit
before,
but
maybe
something
you
can
talk
about
on
the
mailing
list,
a
little
bit
and
what
Rob
or
Sebastian.
A
K
That
was
one
of
us
that
has
that
question.
So,
basically,
with
JD's
work
like
this,
you
can
cut
up
you
deliver.
You
create
your
plugin
in
your
own
repository.
You
github,
hosts
ready
you.
Can
you
basically
open
a
majority
to
the
Jenkins
with
it
with
the
Jay
Kings
team?
They
will
review
your
code
and
ask
you
for
to
fit
the
stuff
where
they
see
fit.
Instead,
all
that
stuff
is
done
and
ready.
K
The
other
advantage
is
that
by
doing
that
is
that
also
you
do
that
that
plug-in
belongs
to
Jay
Kings
community
so
for
a
year
for
any
reason
that
you
kind
of
can't
maintain
it
anymore.
Harden
are
interested.
Maybe
you
see
you
change
your
your
job
or
something
like
that.
Then
someone
can
send
an
email
to
the
mainland
saying
that
they
want
to
become
that
then
the
owner
or
contributor,
and
if,
if
the
one
objects
that
then
you
basically
move
move
it,
they
could
the
owner
of
their
post
heart
to
this
new
person
and
so
on.
A
And
this
is
kind
of
my
take
away
from
that
is
twofold:
one
is
there
is
a
way
to
just
bear
these
things
so
that
other
people,
people
can
use
them
and
then
there's
it's
more
of
like
a
source
of
truth
like
is
get
and
has
like
a
kind
of
that
operational
model
such
that
information
is
not
lost.
If
somebody
like
deleted
their
account
or
something
like
that,
so
that's
interesting.
K
A
Yeah
that
sounds
familiar
just
in
concept,
a
lot
of
other
things
out
there
successful
communities
so
I'm
glad
you
brought
that
up
and
then
kind
of
parallels
with
some
of
the
thoughts
of
word
I'm.
Thinking
about
that
sub
mentioned
around
like
testing,
for
example,
we'd
love
to
have
a
way
to
test
everybody's
operators.
So
if
we
can
instrument
the
SDK
such
that
you
know,
you
can
test
the
failover
and
scaling
or
whatever
mechanisms
that
your
operators
providing.
We
can
test
those
against
different
versions
of
kubernetes,
and
so,
if
there's
any
braking,
API
changes.
A
K
After
that,
the
thing
that
was
the
my
main
motivation
behind
that
question,
because,
as
a
as
a
you
mentioned
before
that
you
don't
vote
for
chosen
operators,
they're
just
they're,
just
as
a
showcase
for
what
you
can
use
that
and
then
having
Khurram
like
and
an
official
organization,
or
something
like
that
for
operators
that
would
imply
that
one
of
the
requirements
belt-like
chose
are
tested.
They
do
have
a
continuous
integration,
continuous
appointment
test.
They
could,
they
can
be
hosting
some
container
repository
as
well.
So
that's
not
that's
that
the
Jenkins.
K
A
B
B
Kook
on
North
America
is
coming
up
in
Seattle
and
I'm
I'm
hosting
an
open
ship
Commons
gathering
day
there
and
I
was
just
going
to
put
it
out
there
that
maybe
that
would
be
a
good
time
to
have
a
face-to-face
operators
type
meeting.
So,
if
you're
interested
in
that
or
helping
to
organize
that
reach
out
to
me
and
I'll
figure
out,
you
know
how
much
time
we
need
in
space
and
I'll
were
the
Rob
and
everybody
else
to
see
if
they
can
make
that
happen.
B
We
could
figure
out
space
issues
and
things
like
that
next
meeting
would
be
in,
for
this
I
think
is
going
to
be
the
third.
The
17th
of
August
is
what
I
have
it
again
at
9:00
a.m.
Pacific
at
that
time
and
date
works
for
everybody
and
just
like
to
keep
repeating,
because
I'm
kind
of
like
that,
if
you
think
we
need
it
or
sooner
than
that,
let
me
know
on
the
mailing
list
and
Shawn
I'm,
putting
you
down
as
one
of
the
possible
speakers
an
ansible
operator
and
next
next
time.