Building an external CPI for CloudStack

Editor's Notes

• #4: We’re working at Orange, one of the leading telco operator in Europe and Africa: 240M subscribers, 29 markets. Orange is a federated group composed of various subsidiaries. A short disclaimer, we’re not speaking for all of orange entities. Pierre Oblin and myself are working in an Orange Group corp focussing on Paas and particularly cloudfoundry. Today, we’re presenting a return on experience developping a CPI for cloudStack, that we built for one of our major Orange France division running CloudStack Xen for some of its internal workload. Why ? We need a production-grade CS CPI for this Orange France division. No official CPI for cloudstack Community work by NTT and ZJU-SEL university not maintained anymore, and not used by their authors So we built one and we’re committed to support it on production activities.
• #7: A bosh agent within vms which turns tasks on behalf of bosh director. Bosh intro stemcell release, deployment manifest bootstraping process bosh-init external cpi bosh-director cpi http://bosh.io/docs/build-cpi.html https://www.gliffy.com/go/html5/9236073?app=1b5094b0-6042-11e2-bcfd-0800200c9a66
• #8: With more details, the CPI actually drives the Iaas and the bosh-agent. The bosh-agent is a versatile process which configures the operating system to leverage Iaas-provisionned resources (network interfaces, disks), and perform other bosh tasks (jobs compilation, jobs instanciation…) The CPI asks the Iaas to instanciate vm templates, vms, volumes and possibly other constructs (floating Ips, security groups, connect LB…) The bosh agent is initially driven by the CPI through the bosh-registry, and then by bosh through NATS-based messaging. The registry provides bosh-side meta data to the bosh agent. The CPI can be made external to the bosh director ruby process, enabling plug-in implementations such as the one we’re presenting today for cloudstack, implemented in different languages than bosh, ours is in Java https://www.gliffy.com/go/html5/9205487?toke=&app=1b5094b0-6042-11e2-bcfd-0800200c9a66&dev=false
• #9: Now that we’ve seen on overview of the CPI interaction, let’s zoom on the CPI API, that is, the contract between bosh director and the CPI CPI API V1 is an RPC style API. It uses serialized JSON on standard input as request, and json on standard output as response, with stderr providing additional responses.
• #11: The bosh agent follows multiple stages: step 1 Tells where to get bootstrap settings step 2: Get access to the registry step 3: Load config from registry step 4: Dynamically reload config
• #14: Flexibility - orange cloudstack networking design (adv zone) - leverage cloudstack local storage capability Bosh active development: bosh-init external cpi light stemcell Lack of public infrastructure enabling community contributions - concourse not available to us: no proxy support for corporate proxies - lack of public cloudstack instance for public ci
• #15: ruby, go, java ? - existing ruby and go frameworks - existing cloudstack_cpi code base internal Java skills, makes Java and springboot a productive platform for us (spring boot actuator and prod ready features) not much low level system iteraction or native libs making java an obstacle. - good cloudstack library: jclouds => a java CPI framework potentially reusable stemcell: mock mode: duplicate existing cloudstack template
• #18: Review our code Test it, submit issues, contribute. Benefits from official CPI V2 API future migration take into account cloudstack API cf-release stubs avoid duplicated ci