Aeolus Developer Conference - Monday, Nov. 5 meeting notes
Tomas Sedovic
tsedovic at redhat.com
Wed Nov 14 14:24:31 UTC 2012
On 11/13/2012 10:10 PM, Matt Wagner wrote:
> 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
>
This is good stuff. Thanks for sending the notes, Matt!
More information about the aeolus-devel
mailing list