[aeolus-incubator/tim] e0fd95: Added Image Import Ability
by Jason Guiditta
Branch: refs/heads/master
Home: https://github.com/aeolus-incubator/tim
Commit: e0fd95c4b1b697d999d50f93728b40e9784e9934
https://github.com/aeolus-incubator/tim/commit/e0fd95c4b1b697d999d50f9372...
Author: Martyn Taylor <mtaylor(a)redhat.com>
Date: 2012-11-23 (Fri, 23 Nov 2012)
Changed paths:
M Gemfile.lock
M app/models/tim/base_image.rb
M app/models/tim/provider_image.rb
M app/models/tim/target_image.rb
M app/views/tim/base_images/_base_image.xml.haml
A db/migrate/20121115151914_add_import_to_tim_base_images.rb
M spec/controllers/base_images_controller_spec.rb
M spec/controllers/provider_images_controller_spec.rb
M spec/controllers/target_images_controller_spec.rb
M spec/factories/tim/base_image.rb
M spec/factories/tim/image_version.rb
M spec/factories/tim/provider_image.rb
M spec/factories/tim/target_image.rb
M spec/models/dummy/provider_account_spec.rb
M spec/models/dummy/provider_type_spec.rb
M spec/models/image_version_spec.rb
M spec/models/provider_image_spec.rb
M spec/models/target_image_spec.rb
M spec/views/provider_images_spec.rb
M test/dummy/db/schema.rb
Log Message:
-----------
Added Image Import Ability
Commit: 2d6caa72090f552f8b66d0401211eab0cab9cd8c
https://github.com/aeolus-incubator/tim/commit/2d6caa72090f552f8b66d04012...
Author: Martyn Taylor <mtaylor(a)redhat.com>
Date: 2012-11-23 (Fri, 23 Nov 2012)
Changed paths:
M README.rdoc
Log Message:
-----------
Included Import Example in README
Commit: 79581d69e9fe16c346a113131863f27cdbfc6a90
https://github.com/aeolus-incubator/tim/commit/79581d69e9fe16c346a1131318...
Author: jguiditta <jguiditt(a)redhat.com>
Date: 2012-11-26 (Mon, 26 Nov 2012)
Changed paths:
M Gemfile.lock
M README.rdoc
M app/models/tim/base_image.rb
M app/models/tim/provider_image.rb
M app/models/tim/target_image.rb
M app/views/tim/base_images/_base_image.xml.haml
A db/migrate/20121115151914_add_import_to_tim_base_images.rb
M spec/controllers/base_images_controller_spec.rb
M spec/controllers/provider_images_controller_spec.rb
M spec/controllers/target_images_controller_spec.rb
M spec/factories/tim/base_image.rb
M spec/factories/tim/image_version.rb
M spec/factories/tim/provider_image.rb
M spec/factories/tim/target_image.rb
M spec/models/dummy/provider_account_spec.rb
M spec/models/dummy/provider_type_spec.rb
M spec/models/image_version_spec.rb
M spec/models/provider_image_spec.rb
M spec/models/target_image_spec.rb
M spec/views/provider_images_spec.rb
M test/dummy/db/schema.rb
Log Message:
-----------
Merge pull request #60 from mtaylor/import
Import Images, resolve issue #42
Compare: https://github.com/aeolus-incubator/tim/compare/a3d0e9247473...79581d69e9fe
11 years, 4 months
Aeolus API and DMTF CIMI
by Tomas Sedovic
Good news everyone!
During our discussions about the Aeolus API at the first Technical Cabal
meeting, Michal Fojtik suggested we look at the CIMI spec (which
Deltacloud partially implements).
Apparently, it tackles a lot of things we are or will be discussing
here, too. Things such as state changes, multi-instance deployments,
networking, etc.
You can download it from the DMTF website:
http://dmtf.org/sites/default/files/standards/documents/DSP0263_1.0.1.pdf
It's a *massive* document (178 pages, ffs) but I think it may be worth
checking it out.
Thomas
11 years, 4 months
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, 4 months
Deltacloud Community Call #2
by Michal Fojtik
Hi,
Is my pleasure to invite you all who are interested in Deltacloud API to
join our community call that will be held on:
Thursday, 22th 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 use Google+ hangout for this and we will also broadcast hangout on
youtube (the broadcast URL will be announced in mailing list and on
IRC). The video recording will be available after the meeting.
This meeting agenda:
* Networking API discussion
* General discussion / questions
Feel free to propose other agenda topics.
More details about the meeting: http://openetherpad.org/DeltacloudCall
Cheers!
-- Michal
--
Michal Fojtik <mfojtik(a)redhat.com>
Deltacloud API, CloudForms
11 years, 4 months
Replacing Cucumber
by Martin Povolny
Hi.
Many of the developers agree with dropping cucumber. No one was against
it. Reasons where given in a different thread.
Some of you expressed need to discuss this topic so I would like to open
a discussion on what we do next.
We probably do not want to have each test written in a different way so
we have to agree on a way.
I suggest writing controller and view tests using RSpec and Capybara.
Different ideas?
I accent that I do not want to rewrite anything I just want to allow
faster creation of tests using more programmer-friendly tools to get
better test coverage.
Can we agree on this?
--
Martin Povolny <mpovolny(a)redhat.com>
tel. +420777714458
11 years, 4 months
Martyn PTO 22/11/2012
by Martyn Taylor
As the subject suggests, I am on PTO tomorrow. Will be back Friday.
Regards
Martyn
11 years, 4 months
Dropping Cucumber
by Martin Povolny
I don't want to get into any big discussion given I guess many people
share my point of view on this. Just +1 if you agree, please.
>From a programmer point of view cucumber tests are not easy to read. You
have to look into the code to find out what is behind the sentences.
And vice versa: you have to check the patterns to see what they really
do when you write new tests.
It just slows things down and brings no real value. The only people
reading the tests are technical people anyway.
I wondered why we have such small coverage in the cucumber tests that
anytime I wanted to add something to a test so far, I found there was
actually no test. I do not wonder any more if writing UI tests with
cucumber is such a pain.
With a lower level tool, we could be much more productive. I have been
doing web automation using low level tools like PERL WWW::Mechanize and
Ruby Mechanize and have to say, that with such tools, you get really
very productive. Much more productive then when using cucumber.
I suggest using rspec with capybara or directly capybara's DSL. Actually
I really do not care as long as I don't have to keep loosing time
playing with cucumber.
To make it clear I do not suggest rewriting existing tests. But when
writing new ones and doing major refactoring I suggest not using
cucumber.
So please do not start a discussion on what we should use instead of
cucumber, just +1 or -1 for not forcing cucumber.
Thank you!
--
Martin Povolny <mpovolny(a)redhat.com>
tel. +420777714458
11 years, 4 months
Re: [aeolus-comm-mgmt] Aeolus Mission voting. VOTE REQUIRED BY NOVEMBER 19 PLEASE.
by Hugh O. Brock
Aeolus Mission voting tally
===========================
The choices:
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?")
Member #1 #2 #3
==============================================
Justin Clift X
Steve Linabery X
Nitesh Narayan X
Matthew Miller X
Matt Wagner X
Mo Morsi X
Tzu-Mainn Chen X
Jaromir Coufal X
Scott Seago X
Andy Fitzsimon X
Tomas Hrcka X
Imre Farkas X
Jirka Tomasek X
Francesco Vollero X
Jiri Stransky X
Giulio Fidente X
Tomas Sedovic X
Martyn Taylor X
Jan Provaznik X
Jozef Zigmund X
David Busby X
Brian Mclaughlin X
John Eckersberg X
Petr Blaho X
Jason Guiditta X
Crag Wolfe X
Mike Orazi X
==============================================
Totals 4 15 8
Number 2 has it, by a substantial margin.
The mission of the Aeolus Project, as voted by its contributors, is
therefore:
"To provide superior tools and workflows for flexible construction,
management, and monitoring of multi-instance deployments across
clouds."
Website cabal, could you see to it that this gets displayed somewhere
prominently?
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, 4 months