Building an external CPI for CloudStack
•Transferir como PPTX, PDF•
0 gostou•1,694 visualizações
- The document discusses the design and development of an external CPI for CloudStack to be used with Bosh. - Key design decisions included choosing a programming language, how to handle the CloudStack API client, and how to integrate with Bosh components like the stemcell, director, and agent. - The CloudStack CPI supports basic VM and disk lifecycle operations and networking features. Future work includes supporting additional CloudStack features and improving test coverage. - Challenges included a lack of documentation and reference implementations, and opportunities for Bosh improvements like CPI daemon support and IaaS-specific registry implementations were identified.
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a Building an external CPI for CloudStack
Semelhante a Building an external CPI for CloudStack (20)
Último
Último (20)
Building an external CPI for CloudStack
- 2. Building of an external CPI for CloudStack Guillaume Berche & Pierre Oblin
- 3. Introduction • Who we are • Disclaimer • Goal of this talk • Why did we build a [new] CPI for CloudStack ? @gberche gberche-orange guillaume.berche [at] orange.com poblin-orange pierre.oblin [at] orange.com
- 4. Outline • Bosh & CPI intro • CloudStack CPI design tradeoffs • Status, future work, learnings
- 6. Bosh intro
- 7. Bosh CPI overview • external CPI • cpi drives Iaas & agent • agent role • registry • nats • => director to cpi api
- 8. CPI API V1 overview
- 10. Bosh agent configuration overview 1. load startup settings provided in stemcell i.e. bootstrap settings sources among: meta-data server, config drive, cdrom 2. load bootstrap settings: i.e; iaas-specific initial networking & registry lookup URL 3. initial registry config loading network configs disks 4. dynamic configs through NATs messages network reconfig, disk resize…
- 13. Context and constraints • Provide flexibility for innovation and optimization while remaining opensource • Chicken and egg: CPI and stemcell • Bosh is in active development, incomplete cpi doc • Lack of public ci infrastructure supporting cpi community contributions corp proxies block us running concourse lack public cloudstack instance
- 14. Design tradeoffs • Where to start: stemcell or CPI? • Programming language: ruby, go, java? • CloudStack api client • Child process invocation model • per invocation process or daemon mode? • stdin/stdout or REST facade ? • Stemcell to cloudstack vm templates • location constraints for bosh-init/director ? • from volume or HTTP? • a light stemcell to kick things off • CS dynamic metadata URL • bosh agent evolution ? • stemcell iptables workaround ?
- 16. Status • Supported: ~ CF-feature-ready – in advanced zone networking: static/dynamic Ips – vm & disk life cycle – configureable disk offering (for eph, root, persistent disks) – light stemcell & stemcell upload • Limitations – single persistent disk support (preventing persistent disk resizing) – single nic support – no yet floating ip/vip – no yet disk snapshots
- 17. Future short-term work • Stemcell: Xen (+KVM), Ubuntu+Centos • another infrastructure in bosh/stemcell_builder ? • patch one of the official stemcell ? • Private CI (concourse): BATS + CPI lifecycle tests +… • Local storage for persistent disks • snapshot • live migration • vm placement to existing local storage • Happy collaborate and committed to support the community: contributions welcome! – Extract Java CPI framework ? – Public CI: any public CloudStack instance ? – CF incubator process ?
- 18. Challenges met & potential bosh improvements • documentation: (PR docs-bosh/63) – reference implementations – unit tests / integration tests – bdd/living doc – design docs – API developper docs. • CPI daemon support in bosh-init (Issue CS_CPI/1) • bosh-agent cloud-stack style volume support • Iaas-specific registry impl (Issue CS_CPI/1) – => use NATS for disk mount support ? • bosh-init optim for CPI development • (external blobstore) (Issue bosh-init/17)
- 19. Thanks, Questions ? @gberche gberche-orange guillaume.berche [at] orange.com poblin-orange pierre.oblin [at] orange.com https://github.com/cloudfoundry-community /bosh-cloudstack-cpi-release
Notas do Editor
- 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.
- 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
- 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
- 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.
- 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
- 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
- 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
- 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