On Wed, Mar 30, 2011 at 6:51 PM, Dustin Kirkland <[email protected]> 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 -- ubuntu-server mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
