December 2012 - aeolus-devel - Fedora Mailing-Lists

[aeolus-incubator/tim] cc23b9: Set status on import and snapshot images

by Jason Guiditta

Branch: refs/heads/master Home: https://github.com/aeolus-incubator/tim Commit: cc23b957de2daa561e3523340c5a371a33ce4ab1 https://github.com/aeolus-incubator/tim/commit/cc23b957de2daa561e3523340c... Author: Martyn Taylor <mtaylor(a)redhat.com> Date: 2012-12-18 (Tue, 18 Dec 2012) Changed paths: M app/models/tim/provider_image.rb M app/models/tim/target_image.rb M spec/models/target_image_spec.rb Log Message: ----------- Set status on import and snapshot images Commit: 17f31d3123ef34e157ac3c9b6bc30a699b7f6f2d https://github.com/aeolus-incubator/tim/commit/17f31d3123ef34e157ac3c9b6b... Author: jguiditta <jguiditt(a)redhat.com> Date: 2012-12-18 (Tue, 18 Dec 2012) Changed paths: M app/models/tim/provider_image.rb M app/models/tim/target_image.rb M spec/models/target_image_spec.rb Log Message: ----------- Merge pull request #90 from mtaylor/set_import_snapshot_status Set status on import and snapshot images Compare: https://github.com/aeolus-incubator/tim/compare/9a337d5785dd...17f31d3123ef

11 years, 4 months

1
0
0 / 0

New Conductor 1.1. - Navigation restructuring - Create missing views

by Jaromir Coufal

Hi all, last days, I was working on specifying missing views for new navigation restructuring, I hope that I have prepared all necessary materials so we can start dealing with restructuring. Steps are following: 1) create missing views - these should be unified with all other views we already have (table views) - concept of table is in attachment (very the same as all others, keep concept as is e.g. in Deployables list) - content of tables is in attached mind map What is missing? * Cloud Environments * Resource Zones (Pools) * AppForms (Deployments) * AppForm Outlines (Deployables) * Provider Accounts (* Provider Selection - will stay at Resource Zones for now) What needs to be edited? * View with list of Images * Monitor view 2) restructure the navigation - the instruction will follow after completing the missing views I am attaching all necessary materials. If anybody is interested in helping me with real implementation, speak up, you are definitely welcome since I can't implement all of these by myself :) I hope we will get it soon implemented and start real user testing (you guys). -- 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, 4 months

1
0
0 / 0

Should we include images templates with next major release?

by Justin Clift

Hi all, We have slowly-developing upstream repo of image templates for the existing Aeolus: https://github.com/aeolus-incubator/templates When we do the next major Aeolus release, it would be useful to include them "already bundled" in some useful way. To make it practical though, a few things would need to happen: + Update them to use CentOS 6.x The templates are using various versions of Fedora at the moment, some F16, some F17, etc. CentOS 6.x is one of the primary "supported" platforms for next upstream release, whereas F16 will be completely EOL soon. So we're probably best to update the templates for CentOS 6. Won't have to update them every 6 months after that. ;) + Figure out how to bundle them in said "useful way" + Should they be pulled down by dev-tools, and placed on the filesystem at suitable location? + Should they be pre-populated in Conductor? i.e. just needing the "build" button to be pushed Anyone have thoughts, objections, etc? If this general concept seems like a good idea, we'll get it added to the Release Cabal's next agenda to see what can be done with it. :) Regards and best wishes, Justin Clift -- Aeolus Cloud Evangelist http://www.aeolusproject.org

11 years, 4 months

6
6
0 / 0

Tech Cabal Meeting - December 18th 2012 POSTPONED

by Martyn Taylor

Gents, Due to xmas holidays and other commitments, only 3 people (myself, sseago and jcoufal) managed to make today's Tech Cabal Meeting. Given the low attendance, we decided to postpone this weeks meeting. We'll pick it up when we return after the xmas break, the next meeting will be January 8th 2013. Enjoy your holidays! Regards Martyn

11 years, 4 months

1
0
0 / 0

[aeolus-incubator/tim] de17d9: Fixed reloading of decorators and patches

by Martyn Taylor

Branch: refs/heads/master Home: https://github.com/aeolus-incubator/tim Commit: de17d9bdc0f3c000bdd91291a5cd23d0cffa43e8 https://github.com/aeolus-incubator/tim/commit/de17d9bdc0f3c000bdd91291a5... Author: Jan Provaznik <jprovazn(a)redhat.com> Date: 2012-12-18 (Tue, 18 Dec 2012) Changed paths: M lib/tim/engine.rb Log Message: ----------- Fixed reloading of decorators and patches Commit: 9a337d5785ddc215ee4ccebffd43d55f4ab47798 https://github.com/aeolus-incubator/tim/commit/9a337d5785ddc215ee4ccebffd... Author: mtaylor <mtaylor(a)redhat.com> Date: 2012-12-18 (Tue, 18 Dec 2012) Changed paths: M lib/tim/engine.rb Log Message: ----------- Merge pull request #88 from jprovaznik/loading Fixed reloading of decorators and patches Compare: https://github.com/aeolus-incubator/tim/compare/1841b2e421a9...9a337d5785dd

11 years, 4 months

1
0
0 / 0

[aeolus-incubator/tim] b80c02: Fixed setting of external_image_id returned by ima...

by Martyn Taylor

Branch: refs/heads/master Home: https://github.com/aeolus-incubator/tim Commit: b80c020b33bcb38d69aa89592dada53bfa8f38f7 https://github.com/aeolus-incubator/tim/commit/b80c020b33bcb38d69aa89592d... Author: Jan Provaznik <jprovazn(a)redhat.com> Date: 2012-12-18 (Tue, 18 Dec 2012) Changed paths: M app/controllers/tim/provider_images_controller.rb Log Message: ----------- Fixed setting of external_image_id returned by imagefactory Commit: 1841b2e421a98351aae236d9dc7921b02f1a3c1f https://github.com/aeolus-incubator/tim/commit/1841b2e421a98351aae236d9dc... Author: mtaylor <mtaylor(a)redhat.com> Date: 2012-12-18 (Tue, 18 Dec 2012) Changed paths: M app/controllers/tim/provider_images_controller.rb Log Message: ----------- Merge pull request #87 from jprovaznik/external_id Fixed setting of external_image_id returned by imagefactory Compare: https://github.com/aeolus-incubator/tim/compare/9170a612695a...1841b2e421a9

11 years, 4 months

1
0
0 / 0

[aeolus-incubator/tim] d993a3: Fixed passing provider param to imagefactory

by Martyn Taylor

Branch: refs/heads/master Home: https://github.com/aeolus-incubator/tim Commit: d993a3458565d7aca292fc8acad7328d84bbd615 https://github.com/aeolus-incubator/tim/commit/d993a3458565d7aca292fc8aca... Author: Jan Provaznik <jprovazn(a)redhat.com> Date: 2012-12-18 (Tue, 18 Dec 2012) Changed paths: M app/models/tim/provider_image.rb Log Message: ----------- Fixed passing provider param to imagefactory If provider attribute contains hash, AR creates object from it and provider param sent to provider then looks like this: "provider":{"provider":{"glance-host":"localhost","glance-port":5000}} instead of: "provider":{"glance-host":"localhost","glance-port":5000} Commit: 9170a612695a04c4ed103f3ca9e2eb3bf4728b44 https://github.com/aeolus-incubator/tim/commit/9170a612695a04c4ed103f3ca9... Author: mtaylor <mtaylor(a)redhat.com> Date: 2012-12-18 (Tue, 18 Dec 2012) Changed paths: M app/models/tim/provider_image.rb Log Message: ----------- Merge pull request #89 from jprovaznik/provider Fixed passing provider param to imagefactory Compare: https://github.com/aeolus-incubator/tim/compare/0dc497fa0494...9170a612695a

11 years, 4 months

1
0
0 / 0

RFC: API versioning

by Richard Su

Hi, I'm going to start the discussion on versioning. After some research, a question that I think we should be asking first is does the API need to be versioned at all? Or what do we mean by versioning? I think there are two initial paths. Do we build the API so that it is backwards compatible so that existing clients continue to work as the api evolves in future conductor releases? Or is this not tenable and we should prepare for the inevitable change that will break backwards compatibility and introduce a versioning scheme? * Backwards Compatibilty Leaving discussions about Heat and CIMI aside (which look to be layers on top of a base Conductor API) and if we think our existing models are correct and are stable I think maintaining backwards compatibillity would be the simplest course. This means that once we've released an API, changes should be additive; removing attributes or elements is not allowed. It also means we never remove ways of interacting with the API. If we add a new field to a resource, to maintain compatibility with existing clients it should be possible to create the resource without specifying the new field. We would indicate the version of the API in a header so that the client knows which version it is taking to. And changes to the API will be documented as each version if released. But there is no effort here to make multiple versions of the API available through a HTTP header or URI off of the same Conductor instance. * Versioning A while ago we committed to having the API work off the same controller as the UI. If we decide that the API must be versioned, I think we will need to break the API off to its own controllers. From what I have gathered, most versioning schemes use a namespace to denote a version and each namespace has its own controllers, views, and tests. A new API version would mean copying the current namespace/version into a new directory with its own controllers, view, and tests. There are some gems like Versionist or Rocket Pants to ease versioning. What is not clear to me though is if there is a significant modeling change how would one make different versions of the API continue to work off of the same Conductor instance. Is there a particular requirement that requires us to version the API? I think there will be significant work involved if we do choose to version the API. Is it worth the effort? Or is there some other type of versioning people are thinking about? Your thoughts? ------ Resources I found useful: 1. http://watzmann.net/blog/2012/08/rest-api-evolution.html 2. http://www.mnot.net/blog/2011/10/25/web_api_versioning_smackdown 3. http://fedoraproject.org/wiki/Cloud_APIs_REST_Style_Guide#Compatibility_a... 4. http://railscasts.com/episodes/350-rest-api-versioning

11 years, 4 months

5
7
0 / 0

Current Sprint Deadline Notification

by steve linabery

Hi aeolus community, The current Sprint is nearing completion. Please have your Pull Requests made by Tuesday, 18-Dec-2012, and try to get eyes reviewing your code submissions. Thanks in advance, Steve Linabery (eggs)

11 years, 4 months

1
0
0 / 0

[aeolus-incubator/tim] 99f90b: Return custom Exception on Factory Connection Refu...

by Jason Guiditta

Branch: refs/heads/master Home: https://github.com/aeolus-incubator/tim Commit: 99f90b27a1b2d1da644fda5430c377e69f756b5c https://github.com/aeolus-incubator/tim/commit/99f90b27a1b2d1da644fda5430... Author: Martyn Taylor <mtaylor(a)redhat.com> Date: 2012-12-17 (Mon, 17 Dec 2012) Changed paths: A app/exceptions/tim/exceptions.rb M app/models/tim/provider_image.rb M app/models/tim/target_image.rb M lib/tim/engine.rb M spec/models/provider_image_spec.rb M spec/models/target_image_spec.rb Log Message: ----------- Return custom Exception on Factory Connection Refused Raises a more appropriate exception when Tim can not connect to ImageFactory. Fixes: https://github.com/aeolus-incubator/tim/issues/83 Commit: 0dc497fa04945085da3e8d47554c9e4fc6af57cc https://github.com/aeolus-incubator/tim/commit/0dc497fa04945085da3e8d4755... Author: jguiditta <jguiditt(a)redhat.com> Date: 2012-12-17 (Mon, 17 Dec 2012) Changed paths: A app/exceptions/tim/exceptions.rb M app/models/tim/provider_image.rb M app/models/tim/target_image.rb M lib/tim/engine.rb M spec/models/provider_image_spec.rb M spec/models/target_image_spec.rb Log Message: ----------- Merge pull request #86 from mtaylor/fix_connection_error Fix connection error Compare: https://github.com/aeolus-incubator/tim/compare/5ea2d92e2af9...0dc497fa0494

11 years, 4 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

aeolus-devel December 2012