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