ITSM stands for IT service management. ITSM is a discipline for managing information technology (IT) systems, philosophically centered on the customer's perspective of IT's contribution to the business. ITSM stands in deliberate contrast to technology-centered approaches to IT management and business interaction. In order to differentiate ourselves from other orchestration products we should offer at least an Inventory Management system (ocsinventory) and a Request Tracker (rt).

The purpose of blueprint will keep track of the work needed to be done for integrating the Essex release into Precise.

Instead of using hosts to front the EC2 mirrors, we should move our mirrors to being hosted on S3. There are numerous advantages to doing so -- most notably speed, lower costs, lower maintenance costs, access policies, etc. Using S3 also realizes some cost-savings for Canonical since all intra-zone transfers are free. Summary: 1. New mirrors would be setup in each region 2. Scripts would need to be updated to use regional mirrors 3. DNS names would need to be updated

Ubuntu currently has a good first step implementation of CloudFoundry via Ubuntu Server and Juju that is stable and scalable. In this blueprint, we should discuss next steps as well as how to integrate CloudFoundry's current roadmap, features, best practices and experiences with Ubuntu Server and our Juju charms. Things to discuss: - build Cloudfoundry from source - use packages where possible. - ways of expanding our current charms - next step ideas.

In oneiric we updated Xen to a more recent version. In precise we need to do further work including testing to make Ubuntu a solid Host for Xen.

Several items should be worked on during this cycle:    provide a default bridge and lxc.conf    proper reboot    containerized syslog    userns vfs    apparmor support    ARM support    tests in qa-regression-tests    allow mknod in the container by default (and potential udev problems) Update mountall to not require our current /lib/init/fstab hack Community requests?

With the proliferation of new clouds vendors, there is substantial risk of inconsistent user experience on different clouds. Trusting vendors to pull images may not be a reliable assumption. For example, vendors may not see the value in publishing a new release day, refreshed cloud images, and/or a standard user experience assumes that cloud vendors will pull the images. I propose that owing and controlling the publishing of the cloud images provides substantial value to both customers and partners. Leaving vendors or the community to handle populating images on the "greater Cloud" could result in Amazon being the gold standard for the customer experience, with lesser, incomplete or missing experiences on other cloud vendors. If we choose to maintain official ownership over our images on major vendors, we either need to build a publishing systems, provide pull scripts that our partners will run, provide a public glance server or some combination. This meeting it to discuss the strategy and come up with a basic plan of action.

Automated ISO testing runs daily during the current development cycle; we need to re-align to cover more types of install testing including better LVM, RAID and iSCSI root testing and cover new aspects of Ubuntu Server such as Orchestra.

Project Kronos is an initiative to port the XenAPI toolstack to Debian and Ubuntu in order to deliver all packages that are needed to run the Xen Cloud Platform (XCP), via Debian and Ubuntu package managers. In a nutshell, all you will need to do get the latest version of Xen, the XenAPI toolstack and other components delivered in XCP is to execute "apt-get install xapi". This blueprint involves the necessary work to ensure Kronos is installable from the Ubuntu Universe archive for 12.04LTS.

Discuss the future of PowerNap based on the feedback received on conferences where it was presented lately as well as discuss previous defined features.

Apache Hadoop has gained widespread adoption; the various flavours of Hadoop appear to be consolidating and Cloudera have transferred a number of their Hadoop related projects to Apache including Bigtop (the Cloudera packaging for Redhat, Debian and SuSE). Packaging Hadoop for Ubuntu would help support developing a set of rock solid Juju charms for Hadoop by providing a well integrated version of the packaging for Ubuntu. Collaboration with Apache Bigtop would also potentially help support packaging the wider family of Hadoop related projects.

This spec covers testing and usability of various server side management methods such as IPMI, and other management tools.

With the fast growing adoption of the Cloud, the lack of a consistent and efficient power management has become a major concern. A first set of features has been developed since UDS-O. The purpose of this blueprint is to discuss the remaining steps to complete Cloud power management for Precise.

kvm plans:    * 1.0    * spice    * robust caps-lock handling    * vde (needs MIR) Community requests?

CEPH has become a first class object and block storage mechanism, and has integration hooks for key pieces of Ubuntu Cloud Infrastructure. Especially interesting is CEPH-RBD for storing kvm block devices on the scalable CEPH block store, and the Hadoop HDFS shim to replace HDFS with CEPH in hadoop clusters.

The Ubuntu Cloud images are built by a loose confederation of scripts. There is no documentation on how to setup an image build server, nor is there any documentation on the dependencies of the scripts. This blue print seeks to consolidate the information and consolidate the tools to make reproduction of a build server and maintenance of the scripts easier.

We have detected a need for DSL integration in Juju, this would mean that any of the current configuration management applications available. Advantages * Faster implementation of juju on running platforms * Faster testing of juju on individual nodes * Complements the amazing capabilities of juju with some node specific templating For all this we need to talk about: * Ways to export through a RESTful interface metadata from Juju * Ways to implement this so Juju can action on this without problem * Finding ways around the SPOFs Juju roadmap right now has priority on colocation Colocation can be used in colocation mode as well Colocated service has access to filesystem services (whichever they are) and can establish master/slave relationships with the master unit Juju charms can trigger an update of the facter information since it's always stateful, it can be a "trigger" on the update hook So far the best action would be to query the CLI (juju status) and its a very effective way to recover information from juju in a quick (albeit slightly dirty) way ACTIONS [lynxman] write puppet external node classifier for juju status -> puppet: TODO [clint-fewbar] Start project for recovering useful information out of juju status: TODO [juju] after colocation investigate cli interface for local / arbitrary unit / relation info: TODO

The FreeIPA team (https://launchpad.net/~freeipa) has been working with the goal to get the packages included in Debian and Ubuntu. Running an instance of FreeIPA provides an easy to maintain kerberos realm for users and machines, 'AD for Linux'. This is something that has been requested by administrators for years, so it's about time to provide it in Ubuntu as well, even if just as a technology preview and not something fully supported (=in universe). Even though the focus for the LTS is on stability, it shouldn't raise the bar for providing new funtionality in universe too high. The current state of the packaging effort: IPA client - dependencies packaged * certmonger * python-krbv * python-nss - client packaged, testing ongoing [ref 1] IPA server - dependencies mostly packaged * 389-ds * dogtag missing - server packaging shared with the client, currently disabled from building due to concentrating on getting the client running Dogtag cert server - dependencies packaged * tomcatjss - consists of several small components, some of them completed, more or less simple to package the rest, just not got that far yet Ideally, the packages would flow from Debian, though it would mean getting someone to sponsor the uploads. [1] https://www.redhat.com/archives/freeipa-devel/2011-September/msg00408.html

We currently test Ubuntu Server ec2 AMI's at key milestones during the current development cycle; we should expand this todo daily testing of both the current development release and existing supported releases as well to provide assurance that Ubuntu Server cloud images are validated on ec2 and OpenStack.

The current install experience for Ubuntu Cloud Infrastructure is less than optimal: - lack of discoverability - many steps - lack of clean documentation We need to identify what, when and how to improve this, specifically for Ubuntu Cloud Infrastructure and in general for products delivers via orchestra + juju

In Ubuntu we made a lot of effort to get Orchestra. The purpose of blueprint will keep track of the work needed to be done in Precise for orchestra.

Presentation and discussion of the features and fixes the Juju team intends to deliver for the Ubuntu 12.04LTS release

We need to implement performance testing for ARM server supported workloads. The focus is performance compared to the amount of power consumed.

Plans:    * Merge 0.9.8? (Start with 0.9.6 now)    * should removing libvirt-bin shut down its vms and remove bridges?    * netcf    * bash completion Community requests?

Juju is great at adding relationships to workloads but has no idea how to automatically scale based on compute requirements. This meeting would discuss adding intelligence and the different approaches we could use to achieve this functionality.

Discuss the next steps for cobbler to provide improvements, define level of maintainship, to make sure its continuum with Orchestra.

This is the per-cycle discussion on what should be improved in the cloud images or in cloud-init.

Charms need to be tested by an automated test runner on each commit to the charm store. There is a need to test each charm's use of each interface with any charms which implement the other side of the interface.

PHP is about to make a new "minor" revision bump, from 5.3 to 5.4. This will remove some long standing security problems like register_globals, and add some advanced new features like Traits. The 5.3 series, meanwhile, will be coming to an end sometime sooner than the end of 12.04's 5 year supported cycle. In the interest of shipping an advanced but stable LTS, we should consider shipping 5.4.0 as the PHP version in 12.04 rather than 5.3.9.

Discuss the current HA cluster stack and its usage in OpenStack and finish with the merges of newest upstream changes. Additionally, discuss the adoption of Pacemaker Cloud [1]. "The Pacemaker Cloud project provides high levels of service availability for high scale cloud deployments. Our approach to high availability is to detect failures, isolate failures, followed by restart of the failed components. When repeated component failures occur the software escalates those failures into failures of higher level components." "" [1]: http://pacemaker-cloud.org/

Since Diablo, Openstack continues to grow at a rapid pace. As it will likely continue its pace throughout the Essex & P cycles, we need to determine which components, functionality and configurations matter most to us and how to test. With Juju driving automated complex deployment testing, we should drill down on specific areas of the stack that are critical to the success Ubuntu Cloud LTS. We should also consider how our testing can make use of upstream's existing QA infrastructure and how our efforts can benefit the Openstack community as a whole.

The current set of Ubuntu Cloud Infrastructure charms to deploy openstack are the best we could do given the constraints provided by the current version of juju. Given that juju has an aggressive roadmap for 12.04LTS that will address it's production tagged bugs (https://bugs.launchpad.net/juju/+bugs?field.tag=production), we should define precisely what the charms should deliver.

The archive needs a rich set of modern packages for "WebScale" operations, review the list of unpackaged technologies and target popular new technologies which need packaging. Whiteboard will contain a list of low hanging fruit with a positive impact.

Discuss cloud new utilities that can be added to cloud-utils or new packages that Ubuntu should bring in.

Complete and publish https://juju.ubuntu.com/AppArmor. (currently in draft)

Cloud-live project delivers usable and bootable cloud infrastructure. Purpose of this blueprint is to set and define goals for the future of the project.