Aeolus Tech Cabal: 20/11/2012 - Minutes
by Martyn Taylor
Please find Aeolus Tech Cabal initial meeting minutes below.
Next weeks Agenda can be found here:
http://openetherpad.org/AeolusTechnicalCabal
You must add items to the etherpad if they are to be discussed in next
Cabal meeting. Anyone wanting to add items to the Agenda then please do
so by 26/11/2012. This will give people a chance to do some preparation.
Next meeting 27/11/2012
Regards
Martyn
Aeolus Tech Cabal: 20/11/2012
Attendees
* Tomas Sedovic
* Martyn Taylor
* Jason Guiditta
* Scott Seago
* Eric Healms
* Michal Fojtik
* Greg Blomquist
* Jaramori Coufal
Agenda
Procedural Items
*Meeting Format: Hugh will send format to the list before next Cabal
Meeting*
* Meeting Time:
o 2pm Tuesday Recurring.
o 1 hour max.
o Items not covered will be raised in next meeting
* Awesome
o 1st Post: Martyn Taylor
o Respoibilities
+ Ensure agenda is adequate
+ Ensure meetings move forward.
* Secretary:
o Weekly rotation: Next: Greg Blomquist
o Responsibilites
+ Take Minutes
+ Distribute Minutes
Technical
API Resource Representation.
1. When shall we use full resource and minimal (link) resource
representation in the API?
2. How should we allow client to access these resources?
Martyn Proposed we represent full resources in all top level
collections. Sub resources will be represented as a collection (with
url) when one to many relationship is present. Sub resource collections
will include minimal resources.
Scott agreed this could solve many of the issues we are currently facing
with the API and would be useful in the API.
Greg mentioned that this could cause some issues with configure. But
will seek advice from Eck
Cabal voted in favour of proposal.
Actions:
* *Greg* will Confirm with Eck
* *Martyn* will send mail to list further explaining the proposal.
* *Martyn* will inform API contributers of changes.
Instance State Machine
1. How do we represent state changes in the API? Particularly for
instances, deployments and deployables.
Michal spoke about using actions and links that represent state changes.
It was agreed that this is not strictly RESTful. Discussion around pure
REST v usability started, but the Cabal came to no conclusion on the matter.
Michal advised us to take a look at the CIMI documentation
(http://dmtf.org/sites/default/files/standards/documents/DSP0263_1.0.1.pdf).
Since the API resembles ours in many ways.
Actions:
* CIMI investigation
* Further discussion on the list.
* Initial topic next meeting. (If unresolvable on list)
Outstanding Agenda Items
1. API versioning - Supporting for versioning the API (Not for
supporting multiple version)
1. URL v HTTP Header (Server HTTP header?)
2. e.g.
http://docs.openstack.org/api/openstack-identity-service/2.0/content/Vers...
2. API Paging/Filtering/Sorting?
1. http://blog.apigee.com/detail/restful_api_design_can_your_api_give_develo...
3. API Race Conditions
4. Handling Deltacloud exceptions in Deltacloud - What need to be done
to improve it..
5. Callbacks in Deltacloud - When, how and who :-)
11 years, 5 months
Website Cabal Minutes, Nov. 20th 2012
by Tzu-Mainn Chen
November 20
Attendees:
Matt Wagner (Awesome)
Tzu-Mainn Chen
Jiri Stransky
Mo Morsi
Francesco Vollero
https://www.youtube.com/watch?v=zWayFPCv0ro&feature=plcp
------------
- Quick review of github issues
- broken Google links need to be investigated further (https://github.com/aeolusproject/aeolusproject.github.com/issues/13)
- others will be discussed through github issues
- Label issues in github (Bug, Enhancement, etc)
- Presentations - wiki vs website?
- presentations uploaded to static site because of potential wiki moves
- wiki organization
- will discuss over email
- focus on website content before worrying about SEO
- enhance about page
- mission statement, high-level picture, link to projects
- change developer's link to updating contributor's page
- website cabal responsibilities vs publicity cabal responsibilities
- publicity about content, website about infrastructure
- overlap exists, but some people are on both cabals, can help coordinate
- new documents directory structure in github for cabal minutes, presentations, etc
- new website section for featured items?
- actually, tag blog posts, aggregate
-------------
- new issues:
- update about page (https://github.com/aeolusproject/aeolusproject.github.com/issues/28)
- change developer's link to contribute (https://github.com/aeolusproject/aeolusproject.github.com/issues/27)
- "featured" page (https://github.com/aeolusproject/aeolusproject.github.com/issues/29)
11 years, 5 months
Aeolus Mission voting. VOTE REQUIRED BY NOVEMBER 19 PLEASE.
by Hugh O. Brock
Mission Statement Voting
OK... I promised to schedule a vote for today and naturally I am
behind. The good news is this means you guys have the weekend to think
about this.
A bit about process. Having been through a substantial mission
statement exercise already, I'm not inclined to lengthen the process
much further by accepting further tweaks. I am therefore going to
exercise the mighty ><}}}*> one final time and reduce the nominees for
Aeolus Mission Statement to three. I hope you all will view this less
as an act of oppression and more as an act of getting the hell on with
it :).
In voting, I would urge you all to remember that a mission statement can
and probably should be aspirational -- our software may not fill our
mission today, but we intend that it will someday, and that new
additions to Aeolus will be included or not based on how well they will
help us fill the mission.
The choices, then, are:
1. Aeolus mission: To provide superior tools and workflows for flexible
construction, management, and monitoring of multi-instance systems
across clouds. (This is the original version we concocted at the dev
conf.)
2. Aeolus mission: To provide superior tools and workflows for flexible
construction, management, and monitoring of multi-instance deployments
across clouds. (Modifications by Giulio Fidente and Justin Clift,
received at least one endorsement on list.)
3. Aeolus mission: "To provide open source tools for the management
and monitoring of cloud based systems." (Alternative from Mo Morsi. Mo
says: "Are we just focusing on 'multi-instance systems'? Isn't
providing simple tools to build images and launch a single instance
against any generic cloud provider part of Aeolus?")
Vote for one by end of Monday, please.
Thanks,
--Hugh
--
== Hugh Brock, hbrock(a)redhat.com ==
== Engineering Manager, Cloud BU ==
== Aeolus Project: Manage virtual infrastructure across clouds. ==
== http://aeolusproject.org ==
"I know that you believe you understand what you think I said, but I’m
not sure you realize that what you heard is not what I meant."
--Robert McCloskey
11 years, 5 months
Publicity Cabal - Next meeting
by Angus Thomas
The meeting will be at 13:30 UTC on November 21st
I'll start a g+ hangout. Find me in #aeolus on freenode if there are any
issues
Standing agenda is here:
https://redmine.aeolusproject.org/redmine/projects/aeolus/wiki/Publicity_...
In addition to the regular items, we will begin the cabal with the
election of the Awesome.
In the absence of a simple, reliable, secure, free voting app, the
election will be by a simple show of hands on the hangout.
(Anyone who can't participate, but wants to have their vote counted
should contact me)
So far, two people have let me know that they're interested in being the
Awesome: Justin Clift and Tzu-Mainn Chen.
Regards,
Angus
The soon-to-be-former Awesome
11 years, 5 months
Re: Aeolus Mission voting. VOTE REQUIRED BY NOVEMBER 19 PLEASE.
by Hugh O. Brock
On Fri, Nov 16, 2012 at 04:27:55PM -0500, Mo Morsi wrote:
> On 11/16/2012 03:28 PM, Hugh Brock wrote:
> > Mission Statement Voting
> >
> > OK... I promised to schedule a vote for today and naturally I am
> > behind. The good news is this means you guys have the weekend to think
> > about this.
> >
> > A bit about process. Having been through a substantial mission
> > statement exercise already, I'm not inclined to lengthen the process
> > much further by accepting further tweaks. I am therefore going to
> > exercise the mighty ><}}}*> one final time and reduce the nominees for
> > Aeolus Mission Statement to three. I hope you all will view this less
> > as an act of oppression and more as an act of getting the hell on with
> > it :).
> >
> > In voting, I would urge you all to remember that a mission statement can
> > and probably should be aspirational -- our software may not fill our
> > mission today, but we intend that it will someday, and that new
> > additions to Aeolus will be included or not based on how well they will
> > help us fill the mission.
> >
> > The choices, then, are:
> >
> > 1. Aeolus mission: To provide superior tools and workflows for flexible
> > construction, management, and monitoring of multi-instance systems
> > across clouds. (This is the original version we concocted at the dev
> > conf.)
> >
> > 2. Aeolus mission: To provide superior tools and workflows for flexible
> > construction, management, and monitoring of multi-instance deployments
> > across clouds. (Modifications by Giulio Fidente and Justin Clift,
> > received at least one endorsement on list.)
> >
> > 3. Aeolus mission: "To provide open source tools for the management
> > and monitoring of cloud based systems." (Alternative from Mo Morsi. Mo
> > says: "Are we just focusing on 'multi-instance systems'? Isn't
> > providing simple tools to build images and launch a single instance
> > against any generic cloud provider part of Aeolus?")
> +1
>
> Thanks Hugh, is it in bad taste to vote for my own option? ;-)
Nope :). If you wouldn't vote for it, don't say it.
--H
--
== Hugh Brock, hbrock(a)redhat.com ==
== Engineering Manager, Cloud BU ==
== Aeolus Project: Manage virtual infrastructure across clouds. ==
== http://aeolusproject.org ==
"I know that you believe you understand what you think I said, but I’m
not sure you realize that what you heard is not what I meant."
--Robert McCloskey
11 years, 5 months
