Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Design Summit - Extending ManageIQ with Jellyfish - Nirmal Mehta


Published on

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

For more on Jellyfish, see

Published in: Technology
  • Be the first to comment

Design Summit - Extending ManageIQ with Jellyfish - Nirmal Mehta

  1. 1. Extending ManageIQ: Cloud Service Broker
  2. 2. Cloud Service Brokering
  3. 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. 4. The guts…
  5. 5. DEMO
  6. 6. Our code (Coming Soon) 1.­‐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.­‐allen-­‐hamilton/servicemix – servicemix code and documentaLon 3.­‐allen-­‐hamilton/<chef-­‐cookbook-­‐servicemix or some other nomenclature> – Chef cookbook for ServiceMix 4.­‐allen-­‐hamilton/ManageIQ – MIQ code and documentaLon 5.­‐allen-­‐hamilton/<chef-­‐cookbook-­‐MIQ or some other nomenclature> – Chef cookbook for MIQ 6.­‐allen-­‐hamilton/Marketplace – MP code and documentaLon 7.­‐allen-­‐hamilton/<chef-­‐cookbook-­‐MP or some other nomenclature> – Chef cookbook for MP 8.­‐allen-­‐hamilton/jBPM – no customized code. 9.­‐allen-­‐hamilton/<chef-­‐cookbook-­‐jBPM or some other nomenclature> – Chef cookbook for jBPM
  7. 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. 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