Technical Cabal
by Jiří Stránský
Hi all,
*proposed members of the cabal are in CC, please ACK or NACK your membership by Nov 13*.
Technical Cabal info (mostly what Hugh wrote[1] earlier):
* Mission for Technical Cabal: Make technical and architectural
decisions across the Aeolus project. Settle disputes.
* One of the aims of the Technical Cabal is to have people from
various Aeolus subprojects present on the cabal, so that decisions
can be made effectively across all of the subprojects. On the
other hand, we try to keep the member count reasonably low
to make efficient communication possible.
* 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:
* Tomas Sedovic
* Martyn Taylor
* Jason Guiditta
* Scott Seago
* Eric Helms
* Michal Fojtik
* Greg Blomquist
* Jaromir Coufal (user experience advocate)
*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.
Initial Awesome for the Technical Cabal is Hugh Brock.
[1] https://lists.fedorahosted.org/pipermail/aeolus-devel/2012-November/01319...
11 years, 5 months
Release Cabal
by Jiří Stránský
Hi all,
*proposed members of the cabal are in CC, please ACK or NACK your membership by Nov 13*.
Release Cabal info (mostly what Hugh wrote[1] earlier):
* Mission for Release Cabal: Test, package, and ship upstream
release components. Manage release process and downstream
packaging. Produce release process documentation for team members.
Produce release announcements.
* 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:
* Steve Linabery (initial Awesome)
* Martin Povolny
* Justin Clift
* Giulio Fidente
*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
Converge-UI rename voting (deadline: Friday's evening)
by Jaromir Coufal
Hi all,
we are voting for renaming Converge-UI project. Idea is to move away
from connection with Katello or Conductor since we are trying to create
independent open source project. If you are interested in participation
and want to influence it, here is where you can leave your vote (each
has 3 votes, keep ordering names by your preference):
https://github.com/Katello/converge-ui/issues/101#issuecomment-10371542
All votes count!
-- Jarda
--
Jaromír Coufal
Interaction Designer
Red Hat Czech s.r.o.
Mobile: +420 724 595 508
E-mail: jcoufal(a)redhat.com
IRC: jcoufal at #cloudforms-ui, #aeolus, #brno
11 years, 5 months
Aeolus Developer Conference Report. ACKS REQUIRED BY NOV 13.
by Hugh O. Brock
Hello Aeolus community!
You've seen some mails over the past week about the Aeolus developer
conference. Hopefully you noticed my youtube links on #aeolus and so
on. We didn't do as good a job as I had hoped we would with sending
out periodic minutes, however, so I wanted to give a brief summary
here as well as detailing some important next steps that various folks
at the conference proposed we take throughout the week.
First I want to give a huge thank you to all the folks who put
together talks for the conference. In no particular order:
Richard Su -- Aeolus API project, Aeolus dev-tools setup, Aeolus
upstream CI testing with Travis
Martyn Taylor -- Rails Engines, TIM (template and image management)
Martin Povolny -- HW Profile cost manager
Jiri Stransky -- Aeolus components and tech committee representation
Steven Hardy -- Heat overview and demo
Tomas Sedovic -- Conductor + Heat, how and why
Imre Farkas -- Automated provider selection
Ian Mcleod -- Image Factory overview
Jeremy Perry -- Conductor permissions UI
Jaromir Coufal -- Conductor navigation and list/detail/baseball-card views
Dmitri Dolguikh -- Katello architecture and UI
Tzu-mainn Chen, Jiri Tomasek, Matt Wagner, Francesco Vollero --
community development
Scott Seago -- Alberich rails engine for authorization management,
stateful instance support concepts
Steve Linabery -- Tagging and packaging with github, productizing with
Brew
Matt Booth -- V2V how and why, v2v future plans
Angus Thomas -- Rationalizing Aeolus object names, Winged Monkey concepts
Mike Orazi -- Organizing upstream projects with github, github issues
Michal Fojtik -- New developments in Deltacloud
Jan Provaznik -- Deltacloud State Tracker
Andy Smith -- Customer requirements and issues
Hugh Brock -- Fixing Aeolus upstream, Aeolus governance
As you can see, nearly the entire team presented on topics from
community building to permissions infrastructure. The presentations
were uniformly well done and really helped give the entire team a
better insight into what the various components actually do.
Second: My major agenda item for the week was Aeolus Project
governance and developing an upstream. I'm happy to report that the
group was able to agree on a set of proposals to take to the list for
comment and hopefully approval. To wit:
* We split into teams, each of which came back with a proposed Aeolus
mission statement. After much discussion we refined the four
proposals into one which reads:
"Aeolus mission: to provide superior tools and workflows for flexible
construction, management, and monitoring of multi-instance systems
across clouds."
Please ACK or NACK-with-suggestions the mission statement by
November 13.
* Resolving direction and technical disagreements among the various
Aeolus projects has become problematic and often leads to
unresolved, festering problems. Therefore the group proposes that we
establish a Technical Cabal, charged with having short, weekly
meetings to set technical direction for the project and debate and
vote on technical and architecture details (What kind of API should
be used here? Does this requirement merit a separate component or
can it be satisfied by project X? etc.). Jiri Stransky will be
sending out a mail with a proposed membership list, which I would
like the community to ACK or NACK this week. In particular, we've
nominated at least a few folks who were not at the meeting; if
you're not interested in serving, fine, register that on the list
and we'll accept nominations for someone else. I will schedule and
chair the first couple of meetings until the Cabal can pick its own
Awesome (the term we, in a moment of insanity, picked to use instead
of "chair"). If you were nominated for the Tech Cabal, please accept
or decline by November 13. If you would like to nominate yourself or
someone else, please do so by November 13.
* We agreed that three other Cabals would be useful: a Website Cabal,
charged with keeping the website up to date; a Publicity Cabal,
charged with managing our appearances at conferences, social media,
slides, papers, etc.; and a Release Cabal, charged with getting
upstream releases pushed out and documenting the required processes
for the rest of the team. Jiri Stransky will have proposed
membership lists for those Cabals out on the list shortly. If anyone
else would like to join one, just ask. We nominated acting
Awesomes for each Cabal to get things rolling until a permanent
Awesome is chosen.
* We agreed that in the future the membership of each Cabal would be
determined by nomination and on-list ACKs, and that terms of
membership should align roughly with release boundaries. Members are
free to serve for as many terms as they like however if re-elected.
* We agreed to propose a roughly six-month release cycle, subject to
adjustments as needed by the Release Cabal. The next two releases
will be on a bit shorter cycle to get us better aligned with
downstream release boundaries: the Release Cabal will propose a
release integrating Factory 2.0 and Deltacloud 1.0.x by the end of
2012 (i.e. two sprints away), followed by another release around the
end of March which will hopefully include a complete Aeolus API. The
first couple of meetings of the Technical Cabal will finalize the
feature priorities for those two releases.
* Each Cabal should have its first meeting the week of November
12. Meetings can be via hangout, IRC, or whatever the Cabal chooses,
but minutes should be published to aeolus-devel.
I'd like everyone with commit access to an Aeolus project to respond
with either ACK or NACK + suggestions to the above proposals, and to
the proposed Cabal membership lists, by November 13. I will consider
failure to respond by November 13 an ACK, as well as an indication
that you're not paying attention.
Third: Matt Wagner, the acting Awesome for the Publicity Cabal,
has volunteered to collect all the presentations given and make them
available on aeolusproject.org. I'll take charge of getting him the
ones I already have, but if you didn't send your slides to me before,
make sure you send them to him now please.
Thanks once more for all the hard work that went into the week. I am
very excited to see what comes next as we begin pushing planning and
feature development upstream and making our releases available to a
wider audience.
Take care,
--Hugh
--
== Hugh Brock, hbrock(a)redhat.com ==
== Senior 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
Website Cabal -- Assemble!
by Matt Wagner
My fellow Website Cabal members,
It's time that we assembled, to fulfill our quest of keeping
aeolusproject.org current and relevant, while identifying and managing
the writing of new content (feature descriptions and documentation). I
know you can't wait!
Trying to get us all to meet at the same time is fairly complicated due
to timezones. I would propose that we meet at the following time:
Thursdays at 14:00 GMT (right after the converge-ui meeting):
9am US/East (Westford)
3pm Brno
12 midnight Brisbane
This is 30 minutes after the current converge-ui meetings which a few
people on this list attend. My thinking is that this helps reduce the
cost of meetings, since Andy (in AU) will already be up for a meeting,
versus trying to have him do 11-12pm calls twice a week.
Could everyone, at their earliest convenience (i.e., right now!) reply
and let me know if this time does or does not work for you?
I would propose that we meet via Google Hangouts. (Please remember to
wear a shirt.) Does anyone object to this? (Using Hangouts, I mean.
Wearing a shirt is non-negotiable.) It makes it easy to do
screen-sharing, and makes it easy for us to record things.
I have also started a quick brainstorm of what we might want to talk
about:
http://etherpad-aeolusproject.rhcloud.com/p/WebsiteCabalInitialBrainstorm
Please note that:
a.) This was just stuff I thought of; please feel free to add more. I
also tried to categorize things in some manner.
b.) I tried to draw a clear line between short-term tasks someone could
do in an hour or so, and longer-term projects that will take some
planning. Both need doing, but I want to make sure we don't lose our
focus.
-- Matt
11 years, 5 months
Re: Please move Community Dev discussions to new mailing list
by Hugh O. Brock
Sounds like I'm the crazy one then :-). Carry on.
-hugh
-------- Original Message --------
From: Scott Seago <sseago(a)redhat.com>
Sent: Thu, 15/11/2012 09:56 AM
To: aeolus-devel(a)lists.fedorahosted.org
CC:
Subject: Re: Please move Community Dev discussions to new mailing list
On 11/15/2012 09:22 AM, Hugh Brock wrote:
> ----- Original Message -----
> From: "Justin Clift" <jclift(a)redhat.com>
> To: "aeolus-devel" <aeolus-devel(a)lists.fedorahosted.org>
> Sent: Thursday, November 15, 2012 4:29:51 AM
> Subject: Please move Community Dev discussions to new mailing list
>
> Hi all,
>
> Now that we have the new "Aeolus Community Management" mailing
> list, please move our Community Development discussions there:
>
> https://lists.fedorahosted.org/mailman/listinfo/aeolus-comm-mgmt
>
> Example threads to move:
>
> * "Aeolus Developer Conference Report" thread
> * [all] Cabal discussion / planning threads
> * [anything to do with mission statement]
>
> Things to not move:
>
> * Patches
> * Aeolus coding topics
> * Technical architecture discussion
> (ie "How should we do persistent state?")
> * Sprint scheduling
>
> Regards and best wishes,
>
> Justin Clift
>
> --
> Aeolus Cloud Evangelist
> http://www.aeolusproject.org
>
>
> This isn't exactly the split I was imagining -- I had thought that coding topics and technical discussion would also go on the new community list. I'm OK with doing it this way, but is this how everyone else understood the split?
>
> --Hugh
I'm confused then. If we're moving everything but patches and pull
request notifications, etc., then shouldn't we be moving the opposite
direction? Keep aeolus-dev and make a new list for patches?
I understood that "aeolus development discussions" would continue as-is
on aeolus-devel, we'd have this new list relating to cabal-oriented
discussions (i.e. things explicitly cross-project and related to
decisions for the cabal, and there was some other possibility of a
separate new list where we would configure a github hook to actually
post the patches associated with pull requests (instead of just links).
Scott
11 years, 5 months
[ANNOUNCE] Release Deltacloud API 1.0.5
by Michal Fojtik
Hi all,
I am pleased to announce the release of Deltacloud 1.0.5. The release is
available from http://deltacloud.apache.org/download.html It will be
available from rubygems.org in the next day or two.
(Please note that Apache mirrors need some time to properly sync the
site update and downloads)
KEYS: http://www.apache.org/dist/deltacloud/KEYS
git tag: release-1.0.5
git repo: git://github.com/apache/deltacloud.git or
https://git-wip-us.apache.org/repos/asf/deltacloud.git
This is a bugfix release. Changes in this release:
* Server
- Added possibility to log into a file (deltacloudd -L option)
- Various fixes and improvements in logging errors
- Advertise operation and parameters for features (/api)
- Fixed memory leak (DTACLOUD-347)
* Drivers
+ Aruba
- Updated API URLs
+ FGCP
- Added possibility to filter instances by realm_id
- Fixed certificate location
+ OpenStack
- Set hardware profile name to OpenStack flavor name
- Fixed .id vs .name issues in create_instance
- Added support for user_data
- DTACLOUD-316, DTACLOUD_328
+ VSphere
- Report instance launch_time properly
- Report time of image creation
+ RHEV-M
- Report time of image creation
* CIMI frontend
- Added support for Collections
- Added support for embedded collections (Machine.disks,
Machine.volumes)
- Added initial support for $expand
- Many improvements to CIMI tests
- Fixed parsing of JSON HTTP body when creating Machine
- Set default content type for CIMI responses
- Added support for $select to Collections
- Fixed order of top-level resources
- Fixed numerous CIMI 1.0 compatibility issues
- Various JIRA fixes: DTACLOUD-350, DTACLOUD-349
* CIMI client
- Fixed various compatibility issues
* EC2 frontend
- Allow to pass user_data to RunInstances (thanks to Oved Ourfali)
Michal
--
Michal Fojtik
http://deltacloud.org
mfojtik(a)redhat.com
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, I'm going to propose the first meeting for the release cabal for
Thursday the 15th, at 18:00 CET (which is GMT+1)
I'd like to use IRC for it, as it happens for fedora[1] and I'm thinking
of a channel called: '#aeolus-meeting'
Ideally we should book such a channel on a shared calendar, also
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 were guides helping to install aeolus on centos.
Having aeolus working on centos looks to me a nice task for the release
cabale as that is probably going to be the preferred distro of choice
for non-paying RPM users.
[1] https://fedoraproject.org/wiki/Meeting_channel?rd=Fedora_meeting_channel
--
Giulio Fidente
11 years, 5 months
RE: Mission Statement - Was Re: Aeolus Developer Conference Report. ACKS REQUIRED BY NOV 13.
by Hugh O. Brock
Apologies folks, I'm out of pocket for the next couple days and haven't had a second to organize this vote. It'll be Friday unless someone else wants to organize it sooner.
-hugh
-------- Original Message --------
From: Justin Clift <jclift(a)redhat.com>
Sent: Wed, 14/11/2012 12:19 PM
To: aeolus-devel <aeolus-devel(a)lists.fedorahosted.org>
CC:
Subject: Mission Statement - Was Re: Aeolus Developer Conference Report. ACKS REQUIRED BY NOV 13.
On 14/11/2012, at 3:00 PM, Scott Seago wrote:
<snip>
> Hmm. OK, I guess to me it's fairly clear that if we can handle >1, we can handle 1 too, but I have no real objections to mentioning both, if it can be done in such a way that everyone agrees to the wording. What is essential, though, is that we do mention multi-instance systems, since that's a huge part of what we do. In other words, by all means lets make it clear that we handle "one or more instances" -- but not at the expense of not making it equally clear that we handle complex multi-instance systems well.
Hmmm, we seem to have started bike-shedding on the mission
statement a while back. ;)
Let's get the list of mission statement candidates written
up, then vote to pick the winner.
+ Justin
--
Aeolus Cloud Evangelist
http://www.aeolusproject.org
11 years, 5 months
