Ubuntu

Ubuntu Orchestra Meta-Package

Registered by Robbie Williamson

 If Ensemble is how you deploy workloads into the cloud, Orchestra is how you deploy "the cloud". Integrating Eucalyptus directly into the Server/debian-installer was a non-trivial exercise. Faced with supporting OpenStack as alternative cloud infrastructure, we'll find ourselves, once again, re-engineering some of the ISO installer. Is this the best approach to the problem of deploying Cloud Infrastructure? Members of the Ubuntu Platform Server Team, in conjunction with the Canonical Solutions Integration Team suggest that we should take a more modern and extensible approach, leveraging the best of open source's bare metal provisioning, management, orchestration, and monitoring technologies -- and we call that "Ubuntu Orchestra".
Step 1: 'apt-get install ubuntu-orchestra-server', which will install and totally configure a suite of free software tools (cobbler, squid-deb-proxy, puppetmaster, mcollective + plugins) on a single machine.
 Step 2: rapidly provision many servers **and/or desktops** over the network, in parallel, adding the ubuntu-orchestra-client package, which results in powerful, managed Ubuntu servers and/or desktops, ready to be purposed/customized/configured/managed/monitored by Puppet. Eventually, Ensemble could/should grow arms to manage physical Orchestra
systems much like cloud instances.

This blueprint involves doing the necessary work in ubuntu-orchestra-server for Step 1 above.

Blueprint information

Status:
Complete
Approver:
Robbie Williamson
Priority:
Essential
Drafter:
Dave Walker
Direction:
Approved
Assignee:
Ubuntu Server
Definition:
Approved
Series goal:
Accepted for oneiric
Implementation:
Implemented
Milestone target:
milestone icon oneiric-alpha-3
Started by
Robbie Williamson
Completed by
Dave Walker

Related branches

Sprints

Whiteboard

Work Items:
ubuntu-orchestra-server MIR: POSTPONED
manpage: POSTPONED
wiki page: DONE
[andreserl] Ship Ensemble kickstart: DONE
[andreserl] Auto-configuration of WebDav storage for ensemble: DONE
[kirkland] Set-up initial environment of imported ISO's for ensemble: DONE
[kirkland] Auto-configuration of DNS/DHCP server: DONE
[andreserl] Switch logging server to use TLS: DONE
[andreserl] orchestra-client should use TLS for logging: DONE
[andreserl] Preseed ca and ssh keys for orchestra-client: DONE

=== SESSION NOTES ===
Ubuntu Orchestra Server
A collection of the best free software services useful in hosting enterprise data center infrastructure services, based on the Ubuntu Server

https://launchpad.net/orchestra
bzr lp:orchestra
ppa:orchestra/ppa

Provisioning Server ( Cobbler, PXE, tftp, ... )

Caching/Proxy/Mirroring ( squid-deb-proxy, debmirror )

Management ( puppet, ensemble?, chef?, etc. )

Orchestration ( mcollective, ... )
`
Monitoring ( rsyslog, collectd, nagios? )

Power Management ( powernap, IPMI?, fence-agents, NUT )
 - PowerNap Server, overtime, should handle IPMI/UPS/etc. Up for discussion in PowerNap session.
 - fence-agents
 - IPMI integrates full power-down, beyond WOL, CPU Idle, etc.
 - Network UPS Tools (NUT) already handles UPS and PDU natively, and IPMI/ALOM/ILO through PowerMan

*Remote Web UI ( Landscape? )

= Requests / Other items =
 * request from Spads in IRC for gpxe support in cobbler
     * Swapping out tftp for http allows you greater debugging and control in your autoinstall behaviors.
     * Many problems reduced to "write a web app"
 * smoser thinks that cloud-init might need some changes that make it more consumable here. Some of the upstart jobs that it does to make it run "really early" might cause issues with networking being less reliable or predictable. this is really just a warning / admission that there might be issues. i *do* think that there needs to be one single thing that does initial first boot installation.
  * It might be useful to allow at the cobbler (or provisioning level) user-data that then would get to cloud-init.
  * somewhat obvious thought... would potentially be nice if there was an ec2-like api cobbler/orchestra
 * cloud-init should be treated as the "configuration management bootloader", i.e., the gateway to being managed by puppet/chef/ensemble/rightscale/etc
 * initial pxe boot image on the network should be a "collect data and report it" image. Then, when a new system is plugged into the network it will boot that image, and report back its mac and cpu/meminfo/disk...

== Actions ==
- pre-execution environment ( boot, collect data about system, report to cobbler )
- discovery step
- hardware configuration

(?)

Work Items

Dependency tree

* Blueprints in grey have been implemented.

Nearby