[Oneiric-Topic] Ubuntu Orchestra

Raphaël Pinson raphink at ubuntu.com
Fri Apr 1 23:28:40 UTC 2011


On Wed, Mar 30, 2011 at 6:51 PM, Dustin Kirkland <kirkland at ubuntu.com> wrote:
> A series of similarly themed blueprints from UDS-Natty in Orlando were
> subsequently combined into a single blueprint [1] in the Natty cycle.
>
> As of 11.04, we have several of the key building blocks now packaged
> in the Ubuntu archive (cobbler, mcollective, etc).  And we have a
> branch at lp:orchestra that provides the basic meta packaging for
> pieces we want to implement using the best of free software:
>  * Provisioning / Installation Services
>  * Configuration Management
>  * Monitoring
>  * Orchestration
>
> There are several limitations to stock ISO-based installs (eg, another
> thread here raises the issue of the limited ISO capacity).  A complete
> network installation service is essential to the future of Ubuntu
> Server efforts.  I envision a situation where the first step in
> deploying a set of Ubuntu Servers is to install the Ubuntu Orchestra
> Provisioning server (apt-get install
> ubuntu-orchestra-provisioning-server, or perhaps run a temporary
> deploy server from a LiveUSB).  Subsequent installations in the
> hundreds or thousands are rapidly and flexibly bootstrapped directly
> from the provisioning server.

One thing I like about FAI is that (afair from a few years back at
least) the live CD uses FAI to install the FAI server itself, using a
special class. All the same, when setting up a puppetmaster, it's
often recommended to begin with the puppetmaster class itself,
ensuring that the machine can install/replicate/manage itself before
it begins installing/replicating/managing others.

I think it could be good to have an install CD specifically tailored
for bootstrapping a provisioning server. After all, that's the only CD
you might ever have to use to get started with your DC.


> Our OpenStack integration efforts for 11.10 will require some
> installation modifications similar to what we did in 9.10 for
> Eucalyptus and UEC.  Rather than hacking through the guts of the
> debian-installer again for this work, I suggest that we build
> OpenStack's installation on top of a modern network installation
> service, as serious cloud deployments necessarily require the
> installation of more than one system.  (Note that OpenStack already
> has a prototype of such a service with the Crowbar project.)


As a note from working in a DC with complex network infrastructure, it
could be useful (but maybe it's not Ubuntu's job) to provide a layout
to control switches. In our infrastructure, we use VLANs extensively
to organize services in sub-networks. We have an installation VLAN
that is not routed and is reserved for machines to be installed via
FAI. I know we're not the only ones doing this, and I believe it's
generally a good practice, since it ensures that your installation
DHCPd will not mess up production machines, and at the same time you
won't have to play with cables either, just retag the switch port to
use a production VLAN (or more than one if necessary) instead of the
installation VLAN. In such infrastructures, it is useful to consider
that the network installation service (or orchestra-like service)
might control switches via SNMP to automatize this step. So the steps
are:

1) Set switch port assigned to machine to installation VLAN;
2) Start network installation (reboot and let pxe +
cobbler/FAI/kickstart/other do its job);
3) Set switch port assigned to machine to production VLAN;
4) Let puppet/cfengine/chef/other deploy software and configure the
machine for production.

I don't expect that Orchestra would impose a VLAN-based network
infrastructure, but maybe it would be great if it provided
functionalities to plug this kind of DC architecture directly in it.
We could consider having such a functionality, and letting people plug
in the SNMP mib they need for their router.

Just an idea, but I think it might make a huge difference for big DCs.
And sorry for the noise if that's already implemented :-)


> A web/network-based installation service would allow the Ubuntu Server
> to modernize its interface and handle far more installation modes and
> workloads than an 80x25 teletype terminal can deliver.  It would give
> the Server Team the ability to integrate new software stacks such as
> OpenStack easily within a single Ubuntu development cycle, something
> that's simply not possible when integral debian-installer changes are
> required (the tasksel menu is the only hook really at our disposal
> right now).  The combination of dynamically generated preseed
> configurations coupled with config-management based post installation
> handling would provide a modern, DevOps-style interface to Ubuntu
> Server installations, and is key to our future.


A web-base service is nice and user-friendly; I'm all for that. But I
don't think it should replace the console tools, or implement
functionalities that the CLI tools don't have. Sometimes you need to
go to machine room, log in to your network installation server and do
things manually, and then you're just happy to have CLI tools that do
the same as the web interface.


Raphaël




More information about the ubuntu-server mailing list