Hi folks, Since we didn't always have an official scribe, I've volunteered to send out the notes I took from the developer conference. Please note that the notes I took were intended for my own consumption, so (a) I didn't write down things that were obvious to me, (b) it's possible I misinterpreted things, and/or subconsciously twisted them to fit my own views; and (c) I sometimes put in my own commentary, or comments from other people during the talks, without clearly marking who said what. IOW, please take this as an overview of what was discussed, but not necessarily an accurate representation of precisely who said what things.
I've started to format this as (a dialect of) Markdown with wikilinks. After whatever discussion/corrections here, I'd like to replicate this information on the wiki, and include links to the relevant slides/materials that were presented. For now, I just have Monday's. Hopefully I'll get the rest out tomorrow. # Aeolus Developer Conference Notes from Monday, November 5th ## Hugh Brock: Upstream & the Future * Aeolus has no real upstream * A strong upstream community has benefits, some non-obvious: * An upstream multiplies developer effort, since people beyond core developers can contribute * It's a customer expectation that Red Hat products have strong upstream communities * A strong upstream brings lots of customer feedback and helps us fit real-world use cases * Is Aeolus relevant without an upstream? Can it survive? * Our mission statement is bad. Beyond the fact that the 'About' page is wrong, it doesn't differentiate us or state how we are better. * We only work on RHEL and Fedora 16. What about other widely-used server platforms, like Debian or CentOS? * We're semi-easy-to-use for developers, but our documentation needs a lot of attention. We don't have as strong a focus on end-users. * Who is our UI aimed at? (Think [[Personas]].) We're trying to serve many at once and not necessarily doing a good job. * Our project is quite complicated, with over 50 models, etc. * mpovolny argues (and I came to agree) that the problem is too many _components_, not necessarily too many models -- and that we should look to write less code, rather than re-inventing the wheel. * While our upstream has been quiet with regards to customers, Red Hat does have customers for CloudForms (the productized version of Conductor + Katello). ## Personas Roles, with some background information, to help us write better use cases. Previous work had come up with 5, though "Developer" might be a valid 6th. These are all up for discussion / edits. ### Marty - Infrastructure Manager * Only uses about 10% of the app, but likely makes the buying decisions * Wants to save the organization time and money * Mostly UI-centric * Cares a lot about things such as usage reporting. ### Sarah - Security Admin * Uses only about 10% of the app, probably also mostly GUI reporting. * Answers questions like: Who can use which accounts, and what images? ### Sam - Sysadmin / Infrastructure Admin * Uses about 40% of the app. * Medium GUI usage, high CLI usage. * Demands a good API * Wants before- and after-launch hooks, some of which may block launching. * Wants alerts, plus a GUI for reporting. * Main user of the admin section * Manages access to cloud accounts; adds and removes cloud resources * Want to manage network and storage clusters (Gluster is oft-requested) ### Dennis - Application Designer * Uses 40% of the application; moderate GUI and moderate CLI. Primarily focuses on the build-and-push UIs, cares a lot about the status GUI. * Assembles systems for others. Builds images for users; would probably want to script this. * Imports images; would convert between formats if we offered that functionality. ### Connor - Infrastructure Consumer * Uses about 50% of the application's functionality, primarily GUI. * Not very well served today. * Wants to do things like launch an image -- but this is surprisingly tough. * GUI for status reports, lifecycle operations, alerting. * Wants console access to images, and an API to script launches. * Wants to launch instances on a specific cloud, or an aggregated cloud. * Interested in high-availability and auto-scaling features. ## CloudForms Product Talk This is a placeholder, as I need to request permission to share some notes from this talk. It was meant for an internal audience and contained some customer details that we may not have permission to share with an external audience. I will follow up on obtaining permission to share anonymized highlights, at least. ## shardy - OpenStack and Heat APIs ### OpenStack * OpenStack: Umbrella project with components talking via REST APIs (externally) and AMQP (internally). All come with client libraries and * CLI tools. (Something we should look at doing.) * OpenStack is led by developers, rather than a top-down approach. * OpenStack components: * Nova - compute node - hypervisor abstraction * Glance - image service (comparable to our iwhd?) * Swift - object store - S3 API + REST API - built-in replication service for redundancy * Quantum - networking - "Network as a Service" with tagged VLANs, etc. -- pluggable "software-defined networks" * Cinder - volume-service mapping block storage to instances; compare with EBS; allows live migrations of instances * Keystone - RBAC/identity management (SQL, PAM, LDAP, KVS); also, a service catalog * Horizon - mostly-stateless web GUI connecting all services * Aside: Check out [[Ceilometer | https://launchpad.net/ceilometer]], which provides monitoring/measurement/metering services, such as for billing. * Aside: http://ken.pepple.info has a lot of great information explaining the OpenStack infrastructure * Latest OpenStack release was Folsom (October 2012); next is Grizzly (spring of 2013?) * Mostly used for dev-ops type deployments; not yet popular with "conservative" firms * RH -- Shipping a fully-supported OpenStack product (in preview) ### Heat Heat is a project in the OpenStack 'incubator' process, seeking to provide orchestration of OpenStack deployments, comparable to AWS's CloudFormation. * Integrates with all OpenStack core components * Uses a JSON template to define a cloud application * Goal: version cloud instance/images like software; repeatable deployments * Permits composite templates -- a template can contain other templates * Provides (or will provide) monitoring of instances, HA failover, and autoscaling ## shadow - Heat and Conductor ### Heat background * Seeks to provide orchestration of cloud applications * Compare with AWS CloudFormation * Orchestration of cloud offerings (AWS includes stuff like S3, EBS, * networking, etc.) * Declarative JSON template * Heat adds a REST API and HA features to the CloudFormation/OpenStack * APIs * Future goals: * Full feature parity with CloudFormations (CFN) * Non-CFN features * Add support for multiple providers? * Potentially become a full-fledged member of the OpenStack core ### Potential for Conductor integration Heat is doing something similar to Conductor, so it might make sense to look at us leveraging their API from Conductor. * Benefits: * Removal of code -- taskomatic, dbomatic, deployment state logic, maybe Audrey * New features -- HA, auto-scaling, monitoring, load balancing, networking... * Modularity -- "do one thing well", plus Heat already has a bigger upstream than we do * Some complications: * The actual change would be rather involved * (Resolved) Heat didn't have a means of talking to Deltacloud (one was written!) * (Resolved) Heat was tied to the OpenStack API (easily changed -- see POC branch) * Open question: How does Audrey fit into this? Heat at least partly overlaps. *phew* That's all from Monday. Please feel free to correct anything I messed up, etc., and I will move this to the wiki soon. Best regards, Matt
