Aeolus Developer Conference - Monday, Nov. 5 meeting notes
by Matt Wagner
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
11 years, 5 months
Publicity Cabal
by Jiří Stránský
Hi all,
*proposed members of the cabal are in CC, please ACK or NACK your membership by Nov 13*.
Publicity Cabal info (mostly what Hugh wrote[1] earlier):
* Mission for Publicity Cabal: Manage and raise Aeolus Project public
profile. Identify speaking opportunities, maintain repos of slides
and whitepapers, manage social media.
* We have four cabals: Technical, Website, Publicity, Release.
* Cabals should have short weekly meetings.
* Membership on the cabal should be for the period of one upstream
release (roughly 6 months, next two releases have a shorter cycle
though). Repeated membership is possible.
* Each cabal has an Awesome, a person who should make sure that regular
meetings of the cabal really happen. Initial Awesomes are appointed,
a proper election of a permanent Awesome should take place on the
first meeting of each cabal.
* Notes about meeting results should be published to aeolus-devel.
Proposed members, as nominated at Aeolus Developer Conference:
* Angus Thomas (initial Awesome)
* Andy Fitzsimon
* Justin Clift
* Francesco Vollero
* Jarda Coufal
* Tzu-Mainn Chen
*Please ACK or NACK your membership by Nov 13.* Also if anyone else
feels that the list of cabal members should be different, speak up please.
[1] https://lists.fedorahosted.org/pipermail/aeolus-devel/2012-November/01319...
11 years, 5 months
committing code that complains a lot in the log
by Martin Povolny
We have an "ošklivý, nepěknou věc" --
http://www.youtube.com/watch?v=7ybnWJ5qZog
-- "ugly, not nice thing" in the repository.
Once I merged Conductor I got a bunch of not-found errors in the
console. It's annoying to search for my bugs in the flood of other
people bugs and it already lasts for several days.
So, please, could you make sure that if you commit to the main the code
you commit does not make the log unusable?
Thanks!
--
Martin Povolny <mpovolny(a)redhat.com>
tel. +420777714458
11 years, 5 months
Deltacloud API Community meeting #1
by Michal Fojtik
Hi,
Is my pleasure to invite you all who are interested in Deltacloud API to join our first
community call that will be held on:
Thursday, 15th November @ 1700 CET (Prague, Brno, GMT+1)
(which means 0800 PST (US West Coast, GMT-8) or 1100 EST (US East Coast, GMT-5))
We decided to use Google+ Hangouts for this. If you want to join us, all you need to do
is to setup a Google+ account and send us your email, so we can invite you.
This meeting topics include:
* Working with Deltacloud API clients
* Contributing patches, review process, etc.
* Networking API discussion
* General discussion / questions
More details about the meeting: http://openetherpad.org/DeltacloudCall
Cheers!
-- Michal
Michal Fojtik
http://deltacloud.org
mfojtik(a)redhat.com
11 years, 5 months
Website Cabal
by Jiří Stránský
Hi all,
*proposed members of the cabal are in CC, please ACK or NACK your membership by Nov 13*.
Website Cabal info (mostly what Hugh wrote[1] earlier):
* Mission for Website Cabal: Keep aeolusproject.org current and
relevant. Identify and manage writing of new content (feature
descriptions, documentation).
* We have four cabals: Technical, Website, Publicity, Release.
* Cabals should have short weekly meetings.
* Membership on the cabal should be for the period of one upstream
release (roughly 6 months, next two releases have a shorter cycle
though). Repeated membership is possible.
* Each cabal has an Awesome, a person who should make sure that regular
meetings of the cabal really happen. Initial Awesomes are appointed,
a proper election of a permanent Awesome should take place on the
first meeting of each cabal.
* Notes about meeting results should be published to aeolus-devel.
Proposed members, as nominated at Aeolus Developer Conference:
* Matt Wagner (initial Awesome)
* Jirka Stransky
* Justin Clift
* Tzu-Mainn Chen
* Andy Fitzsimon
* Francesco Vollero
*Please ACK or NACK your membership by Nov 13.* Also if anyone else
feels that the list of cabal members should be different, speak up please.
[1] https://lists.fedorahosted.org/pipermail/aeolus-devel/2012-November/01319...
11 years, 5 months
updating gems
by Mo Morsi
Before jumping back into isitfedoraruby, I plan on pushing some long
overdue updates to some of the gems I maintain.
The following are on my list:
Must update:
- childprocess: 0.2.0 -> 0.3.6 (BZ #873320, required for rubygem-aruba
update)
Upstream release monitoring
- minitest: 2.10.1 -> 4.2.0 (BZ #798247)
- ruby2ruby: 1.2.4 -> 2.0.1 (BZ #843895)
- ruby_parser: 2.0.4 -> 3.0.1 (BZ #843896, could we use this gem
in gem2rpm?)
- sexp_processor: 3.0.4 -> 4.1.2 (BZ #843897)
- ZenTest: 4.6.2 -> 4.8.2 (BZ #828262)
- sass: 3.1.20 -> 3.2.2 (BZ #847675)
- thor: 0.14.6 -> 0.16.0 (BZ #843898)
--- the following are only point releases so I don't expect any major
problems w/ these:
- webmock: 1.8.7 -> 1.8.11 (BZ #842655)
- haml: 3.1.6 -> 3.1.7 (BZ #847670)
- treetop: 1.4.11 -> 1.4.12 (BZ #871769)
- oauth: 0.4.4 -> 0.4.7 (BZ #746468)
- uuidtools: 2.1.2 -> 2.1.3 (BZ #840762)
- yard: 0.8.2 -> 0.8.3 (BZ #866401)
---
Others:
- authlogic: 3.0.3 -> 3.1.3
- compass: 0.11.5 -> 0.12.2
- cucumber: 1.1.9 -> 1.2.1
- vcr: 1.10.0 -> 2.3.0
---------------------------------
Unless there are any objections, I would like to start pushing updates
to rawhide soon (rawhide only). To assist in the update process, I've
whipped up a little script (which you can find here [1]) called the Gem
Rpm Updater, or gru.rb
This script simply wraps some of the fedpkg commands to checkout a gem
from Fedora, download the latest version from rubygems, and updates the
spec file / builds it via koji.
It automates everything up to the git push and official koji build /
tagging. Most likely it won't catch all edge-cases, and some
intervention will be needed, but it spits out any discrepancies in the
process if it notices them, and I'm hoping if we standardize our
workflow enough, this will work w/out intervention for most packages
(perhaps we could offer another level of compliance in or ontop of
Fedora's Ruby guidelines).
I was able to come up with this over the course of a few hours, but if
there is an interest in it, it could be expanded to handle more of the
process. A next logical step could be to integrate David's ruby wrappers
to the Fedora package API [2] to try to match dependencies from rubygem
and fedora in an elegant manner.
Thoughts?
-Mo
[1] https://gist.github.com/4036394
[2] https://github.com/daviddavis/pkgwat
11 years, 5 months
Release Cabal inaugural meeting
by Giulio Fidente
hi there,
given that each cabal should have its first meeting by the end of this
week, my proposal for the first meeting of the release cabal is for
Thursday the 15th, at 18:00 CET (which is GMT+1)
I'd like to use for this and the next meetings IRC, as it happens for
fedora, I'm thinking of a channel called: '#aeolus-meeting'
We should book such a channel on a shared calendar which will eventually
be published on the website to encourage people join us.
My proposals for the agenda (and please feel free to add other stuff
which you think is important):
* wrap up on the current status of art
* review the existing install docs and look for improvements
* define some 'recurring' date for our next meetings
Note that today we've got a guy on #aeolus asking, amongst other things,
if there guides helping to install aeolus on centos.
Having aeolus working on centos looks to me a nice task as that is
probably going to be the preferred choice for non-paying (yet) customers.
[1] https://fedoraproject.org/wiki/Meeting_channel?rd=Fedora_meeting_channel
--
Giulio Fidente, gpg key id 08D733BA
--
Giulio Fidente
11 years, 5 months
New "Community Management" mailing list
by Justin Clift
Hi everyone,
As per recent thread on the aeolus-devel mailing list,
we've created a new "Aeolus Community Management" mailing
list.
aeolus-comm-mgmt-request(a)lists.fedorahosted.org
It's a place to debate, discuss, co-ordinate (etc) our Aeolus
Community (development) and Management. No patches. :)
If you're interested in Aeolus Community things, but have
been put off in the past by the torrent of patches on
aeolus-devel, this new mailing list is probably for you.
Specific note -> this is a completely public mailing list,
everyone is welcome. :)
Regards and best wishes,
Justin Clift
--
Aeolus Cloud Evangelist
http://www.aeolusproject.org
11 years, 5 months
Website restructuring
by Jiří Stránský
Hi,
here's a mailbomb related to our website. If you're not interested, feel free to skip it :)
I'd like to follow up on Mo's recent pull request and also on the discussions we had on Developer Conference by proposing an update to the website structure.
Here is what I would like to have as main menu items:
* Home - what we have now, with a bit revisited content.
* Projects - the thing that Mo has done. We have so many components now that people deserve a special page just to get the 3048 meter (ten thousand foot) view of Aeolus.
* Install - describe how to download and install Aeolus. "Get It" is fine too, but I just think "Install" is clearer and more common. Regarding content of the page, we should decouple it from Fedora, as discussed on the Conference.
* Docs - point of origin when you search for tutorials, reference guides etc., regardless of who you are. Link to our usage guide with screenshots, links to GitHub wikis (when we have them) of various subprojects, links to API docs. We should make clear what links are for what "persona". I'd differentiate here between three groups: Admins (Sam, the sys admin - installation and setup), Users (Dennis, the app designer + Carl/Bert, the infrastructure consumer - clicking and CLIing), Developers. -- Yeah, Mike, the develper persona might be useful :)
* Contribute - information for everyone who wants to help. What stuff we need - helping newbies, updating tutorials, writing code etc. and how should people get involved (installation for development, finding easy "onboarding" stuff to work on, etc.).
* Blog - feed from our external blog. (Or, we could move the blog to be part of the website. Not sure if there would be issues with this though.) We could get rid of News section, as Mo did in his pull request. I think Blog/News are largely overlapping and we might struggle to find enough items for News section alone. Or, should News stay, I'd let them be only on the Home page with some link to show older news, but I wouldn't put that into main menu. I believe this main menu item wouldn't be used much.
* Contact / Need help? / something else? - not sure of the name here, but the purpose of the page is the same as we have it now - document our communication channels, allow people to reach out for help or give feedback.
That's 7 main menu items, the magical ideal number[1].
Any feedback and suggestions are welcome, and I'd like to subsequently process this on a Website Cabal meeting (the second one, should the first be too soon for this).
Take care,
J.
[1]: http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two
11 years, 5 months
RFC: to show Credential Definitions with Provider Type or not
by Petr Blaho
Hi,
I am working on show action for Provider Type API and I am not sure if I
should include Credential Definitions in XML representation of Provider
Type resource at all (probably bad idea), use only ids and hrefs or if
hsould I include the whole subresource there.
The similar question goes for create action. Should the user
be able to create new Credential Definitions from within Provider Type
data XML provided to create action? And the same for update action.
Or should be Credential Definition resource of its own?
Looking for your input.
--
With Regards
Petr Blaho
11 years, 5 months