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
* 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).
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
* 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
### 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
* 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: 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
* 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
* 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
* RH -- Shipping a fully-supported OpenStack product (in preview)
Heat is a project in the OpenStack 'incubator' process, seeking to
provide orchestration of OpenStack deployments, comparable to AWS's
* Integrates with all OpenStack core components
* Uses a JSON template to define a cloud application
* Goal: version cloud instance/images like software; repeatable
* Permits composite templates -- a template can contain other templates
* Provides (or will provide) monitoring of instances, HA failover, and
## 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
* 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.
* Removal of code -- taskomatic, dbomatic, deployment state logic,
* New features -- HA, auto-scaling, monitoring, load balancing,
* 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
* (Resolved) Heat was tied to the OpenStack API (easily changed -- see
* Open question: How does Audrey fit into this? Heat at least partly
*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.