Jellyfish is a cloud service broker built on top of ManageIQ. Using Drupal for a marketplace GUI, and ManageIQ as the REST API provider and canonical data source, Jellyfish is a multi-cloud broker and service catalog allowing admins to seamlessly grant resources to end users and developers. This presentation goes into the effort of creating jellyfish and what went into utilizing ManageIQ as a backend platform. For more on ManageIQ, see http://manageiq.org/ For more on Jellyfish, see https://github.com/booz-allen-hamilton/projectjellyfish

1. Extending
ManageIQ:
Cloud
Service
Broker

2. Cloud
Service
Brokering

3. Cloud
Broker
Architecture
User Portal or
Marketplace
IaaS
Broker
PaaS
Broker
SaaS
Broker
Data
Broker
Administrator
Portal
TaaS
Broker
Cloud
Orchestration
Engine
XaaS
Broker
Our OPEN CLOUD BROKER is
built on a plug-and-play 3-tier
framework, designed to support:
ü Scalability
ü Modularity
ü Choice
ü Vendor Independence
ü Today’s Requirements
ü Tomorrow’s Challenges

4. The
guts…

5. DEMO

6. Our
code
(Coming
Soon)
1.
github.com/booz-­‐allen-­‐hamilton/Cloudbroker
–
the
link
we’ll
use
to
point
folks
to
the
broker,
with
background
info
and
links
to
other
repos.
We’ll
use
this
link
in
our
press
releases,
arLcles
and
interviews.
2.
github.com/booz-­‐allen-­‐hamilton/servicemix
–
servicemix
code
and
documentaLon
3.
github.com/booz-­‐allen-­‐hamilton/<chef-­‐cookbook-­‐servicemix
or
some
other
nomenclature>
–
Chef
cookbook
for
ServiceMix
4.
github.com/booz-­‐allen-­‐hamilton/ManageIQ
–
MIQ
code
and
documentaLon
5.
github.com/booz-­‐allen-­‐hamilton/<chef-­‐cookbook-­‐MIQ
or
some
other
nomenclature>
–
Chef
cookbook
for
MIQ
6.
github.com/booz-­‐allen-­‐hamilton/Marketplace
–
MP
code
and
documentaLon
7.
github.com/booz-­‐allen-­‐hamilton/<chef-­‐cookbook-­‐MP
or
some
other
nomenclature>
–
Chef
cookbook
for
MP
8.
github.com/booz-­‐allen-­‐hamilton/jBPM
–
no
customized
code.
9.
github.com/booz-­‐allen-­‐hamilton/<chef-­‐cookbook-­‐jBPM
or
some
other
nomenclature>
–
Chef
cookbook
for
jBPM

7. What
we
are
contribuLng
to
MIQ?
API
Changes:
-­‐
Removed
the
need
to
use
the
"acLon"
keyword
in
the
request
payload.
-­‐
The
one
instance
when
it's
required
is
for
reLring/deleLng
since
the
HTTP
DELETE
method
isn't
clear
which
one
you
would
be
requesLng.
-­‐
Updated
all
the
HTTP
methods
so
that
they
are
more
align
with
their
respecLve
acLons.
-­‐
POST
for
creaLng
resource
_
DELETE
for
deleLng
resource
-­‐
PATCH
for
updaLng
resource
-­‐
Added
addiLonal
routes:
ReporLng
-­‐
GET
latest
report
(as
CSV
by
default)
-­‐
POST
to
immediately
queue
a
report
to
run
if
it
doesn't
exist
for
a
sepcific
report
type
-­‐
Returns
the
ID
of
the
report
that
will
be
generated
-­‐
since
the
report
is
queued,
the
id
is
really
the
only
idenLfier
immediately
available
on
submission.
Chargeback
-­‐
GET
retrieve
chargeback
reports
by
ID
-­‐
PATCH
update
rate
informaLon
-­‐
Updated
the
responses
coming
back
from
various
HTTP
methods
so
that
they
provide
meaningful
feedback.
-­‐
DELETE
returns
the
record
being
deleted
(along
with
a
200
response)
instead
of
just
returning
an
empty
response.
-­‐
POST
also
returns
a
200
along
with
the
resource
that
is
queued
to
be
created.
-­‐
"href"
and
"id"
are
consistently
returned
from
most
(if
not
all)
requests
where
applicable.
-­‐
previous
behavior
was
erraLc.
someLmes
came
back
with
the
"href",
"id"
or
both.
this
made
it
difficult
since
when
the
user
needed
the
"id",
it
had
to
be
parsed.
at
the
same
Lme,
having
a
unique
reference
to
the
resource
would
keep
it
RESTful.
therefore,
returning
both
values
should
allow
the
developer/user
more
flexibility
of
which
one
makes
more
sense
to
use
for
their
specific
use
case.

8. QuesLons?
• What
is
a
cloud?
• What
the
weather
like
in
Mahwah?
• How
much
wood
would
a
wood
chuck
chuck?
• What
will
Elon
Musk
come
up
with
next?
• 42