OpenStack Folsom Design Summit

Folsom should be high-security :) What security architectural improvements could we push during the Folsom timeframe ? This includes discussion of encrypted internal communication and further improvements to make the rootwrap less permissive. (Session lead is Thierry Carrez)

What are the pain points for operations staff maintaining openstack installations? There have been some small improvements in essex in this regard (for example trying to log the instance UUID for errors). What else can we do to make it easier for ops people to diagnose faults and explain the state of instances which have gone wrong? (Session lead is Michael Still)

On virtual machine deletion (termination) there needs to be a way to safely transmit the state of that virtual machine (disk state to begin with, memory state maybe later in the future) to a location for a given period of time. This is useful for debugging, tracking and auditing (and even backing up) of terminated machines for a given period of time. Most of this functionality already exists in openstack but there are some slight additions that need to be added. This type of feature should be available for the people that control the cloud as well as users who run on the cloud (as a private company that runs ontop of the cloud may want the same functionality for there own uses). (Session lead is Joshua Harlow)

SPICE is an open source alternative to VNC. It promises much better performance and capabilities than VNC, and could enable desktops-as-a-service with OpenStack. I have a quick POC of SPICE integration here, which attracted a lot of interest: https://review.openstack.org/#change,5319 I hope to evaluate SPICE further (to see if it lives up to the hype), discuss my findings, and work with the community to add support for SPICE to OpenStack. A potential plan of action is: 1) Push (insecure) code that allows administrators to turn on SPICE and evaluate it. 2) Develop a gateway like the novnc gateway that allows secure client access if #1 has good results. 3) Native client port of SPICE C code? (Session lead is justinsb)

The ZeroMQ RPC driver introduces a concept of pluggable matchmaking for bare topics providing a "get_workers" method. This can be used to find a peer to communicate with, a la "compute.host" rather than sending to a bare topic such as "compute". A similar requirement exists in the scheduler when it pulls a list of all hosts from the database (which feeds from RPC). These efforts should be condensed. Having pluggable matchmaking can immediately reduce the scheduler's dependence on the database and has clear advantages for distributed RPC (and potentially for (de)centralized RPC as well). We should brainstorm requirements, where this fits in, etc. (Session lead is Eric Windisch)

Nova has some EC2 compatibility, but could be better. This session will look at how to support users coming from Amazon to OS: what is most needed, and where to add it. This will also include discussion on whether the ec2-api should be managed inside of nova or via an external component. (Session lead is Martin Pool)

The focus of this session is to discuss the current state of High Performance Computing using OpenStack and idenify development priorities and resources to further HPC-class workloads in the next release. Topics include cluster support and topology aware scheduling, I/O issues such as Infiniband support, RDMA-over-*, latency-sensitive I/O, security, etc., large memory guest VMs and compute accelerator access (GPUs, FPGAs, etc.), large data management challenges such as parallel file systems, and integration with HPC ecosystems and tools. (Session lead is BrianSchott)

The attached design proposes an API which would allow instances to be customized via puppet, chef, etc. using a Nova API extension. Several people have expressed interest in this feature; several others have argued that it should be managed outside of the Nova API. Topics of discussion: - Does anyone else want this? - Is adding a Nova API interface for this feature useful? Should it be part of nova-core or an extension? - Is the proposed blueprint missing necessary features or flexibility? - Who will write this and/or who will write tool-specific drivers? - In order to support this, what features do we require from the hypothetical/future guest-agent tools? (Session lead is Andrew Bogott)

One being involved into multiple commercial OpenStack deployments can’t help noticing that one of the most frequent requests from customers is the support of Windows as a guest operating system. At the same time customers expect this support to be somewhat smart compared to the *nix like systems support. Currently there seems to be no better non-hackish solution than guest agents once proposed and implemented by the Rackspace company for Xen-based OpenStack installations. The guest agent is a background service which runs within the guest operating system, receives and executes commands issued by a cloud user via the CLI or web-interface. The sphere of guest agent applications is not limited with Windows-related features support, it includes lots of guest side magic for other guest types as well. Scope of possible applications for guest agents - Instance access recovery = Resetting administrator’s password in a secure manner = Resetting networking configuration to default one - Guest-side preparation of an instance for further snapshotting (in particular actual for Windows instances) - Guest side software installation and configuration (serving as a Chef/Puppet bootstrap) - Block device management = Optional creation of file system on newly attached block devices = Resizing of system partition on instance spawn according to the flavor used - Advanced monitoring of an instance state = Collection of some sophisticated parameters (e.g. disk or memory usage) which can’t be obtained from outside - Updating of guest side PV drivers for a specific hypervisor (e.g. Xen Guest tools) - File system-agnostic file injection Proposed agenda for brainstorming - Responsibilities and functions of guest-side agent - Security considerations, restricting access to instances - Implementation details = Programming language, toolset and packaging for various target OS - OpenStack and guest agent interoperation details = Communication channels in case of different hypervisors = Choosing an appropriate communication model (pull/push, persistent connection/polling etc.) = Definition of low-level communication protocol details - OpenStack-side support for guest agent functions = Existing management command support (like nova set-root-password) = Additional management commands definition and implementation = Extension of Nova API (if required) = Dashboard extension (Session lead is Artem Andreev)