aeolus-devel December 2012

aeolus-devel@lists.fedorahosted.org

34 participants
58 discussions

moving wiki content
by Mo Morsi 19 Jun '13

19 Jun '13

On the website mtg today we discussed moving the redmine wiki content to the individual github wiki's. Matt mentioned we have the capability to mass migrate redmine pages to github wiki pages so we're asking each individual subcommunity which pages they would like to be migrated to their wiki. The overall binding content will be moved to a combination of the conductor wiki and the aeolusproject.org github site wiki. The later isn't the best fit for the content (though alot of the content should go in the conductor wiki) but its the best option that we currently see atm. We threw around the idea of a mediawiki installation but as Matt mentioned we previously had one (got littered with spam) and none of us felt the effort of setting one up was worth the cycles atm (can be revisited in the future). If anyone has any additional suggestions, feel free to shout out here. We are looking at mid January as the cutoff date for this migration. We ask that a representative of each indivual subcommunity (deltacloud, imagefactory, oz, Tim, Heat, conductor, configure, aeolus-cli, and audrey) start looking at the redmine wiki and send us a list of the pages they want migrated. If you could send this to us by mid December that would be more than appreciated. Alternatively just migrate the wiki content you would like and just tell us (don't worry, we will find other things todo ;-) ). We will keep the redmine wiki around after the end of January in read only mode for historical / archival purposes. Though at some point in the far future we most likely will shut it down for good. -Mo

7 22

quickly developing / testing tdl's
by Mo Morsi 16 Jan '13

16 Jan '13

Aaron gave me a good idea yesterday. The script [1] which I whipped up to demo deltacloud on fedora-devel [2] could be used to very quickly test out templates on the cloud. (without having to wait for the long image building process which takes lots of time and bandwidth) The tool is pretty basic, it just sets up a cloud environment via deltacloud with some extra info added to the tdl (the added fields do not overlap w/ the existing tdl ones, so the templates can still be used with oz / imagefactory as is), and runs a ssh loop to process the tdl. The nice thing is I can simplify it even further very easily by removing that ssh loop and simply using oz to process the tdl on the running cloud instance. Essentially this would mean mycloud (the name can be changed) is the simplest unification of deltacloud and oz To prevent confusion, I propose we name these templates w/ the extended cloud data, "extended tdls", or etdl's for short. This would give deltacloud another use case and would make building and testing templates for various purposes very simple and easy. Thoughts? -Mo [1] https://github.com/movitto/mycloud/blob/master/mycloud.rb [2] http://lists.fedoraproject.org/pipermail/devel/2012-November/173298.html

2 5

State Transitions in ReST API
by Martyn Taylor 10 Jan '13

10 Jan '13

Gentlemen, We discussed how to model state transitions in the ReST API in the Tech Cabal and also offline for those who had particularly strong views. One of the objections brought forward was how to distinguish between clients (end users or applications) requesting state changes. For example: A developer decides he wants to terminate his running instances and system services that are used to notify conductor of when an instance has changed state. For example db-o-matic wants to tell conductor that the instance has now started. After some deliberation offline between myself and sseago and without objections from the Tech Cabal. We decided that the services and the end users should access different APIs and we should not add complexity into the end user API in order to support these system services. With this behind us. We then were able to move forward to make a decision on how to handle requests from a user to transition between states. Like in the developer example above. It was agreed that treating the State on an instance as simply an attribute on the resource (and not an action) was more inline with the ReST principal (Since adding actions breaks ReST principal of having a unified interface - in our case the unified interface is defined by HTTP). So, this now brings us to how we should represent these resources. I think this is something that can and should be decided on list. I have included below my opinion on how this should be represented, please add in your own comments. == So in my opinion we should model a state machine as an independent resource. When client wants to change the state of an instance, it looks at the state machine to figure out what are the possible states I can move to now. The instance can hold a reference to it's current state and the state machine. A simple example here: https://gist.github.com/4257951 Regards Martyn

8 15

Sprint review screencasts
by Jirka Tomasek 08 Jan '13

08 Jan '13

The Publicity Cabal has decided that it would be nice to record our sprint review presentations. We concluded that instead of recording whole sprint review call it would be better to make separate screencasts of the presented features. This approach makes each feature introduction shorter and noiseless. I have made a few tests and making screencast is fairy simple on Fedora. The recordmydesktop utility is already installed, I just installed GUI version gtk-recordmydesktop. Then I looked at http://www.youtube.com/watch?v=rWHXbkpJjGk for a couple of configuration advices. I prefer to use 25fps as it gives more fluid experience. The video file then grows quite big though, so set it based on the length of your presentation. Screencast I did has four minutes and video file has been around 70mb. Only tweak I had to do is to lower my mic sensitivity to avoid background noise. After you record the screencast, It is possible to upload it as it is or if you want to do more editing you need to use some video editor (Avidemux). If the video file is too large, you can use HandBrake to compress/convert it. Make sure that compressed video is still watchable:) Here is my Username/Password recovery screencast: http://www.youtube.com/watch?v=cur639p70Vs I will put this guide also to our wiki.

1 1

Fwd: RFC: Image versioning / Component Outline versioning
by Jaromir Coufal 20 Dec '12

20 Dec '12

Re-sending one more time, since I did not find the message on aeolus-devel mailing list after sending it. Please, see below: -------- Original Message -------- Subject: RFC: Image versioning / Component Outline versioning Date: Fri, 14 Dec 2012 14:58:00 +0100 From: Jaromír Coufal <jcoufal(a)redhat.com> To: aeolus-devel <aeolus-devel(a)lists.fedorahosted.org> CC: mtaylor(a)redhat.com, Angus Thomas <athomas(a)redhat.com>, Jan Provazník <jprovazn(a)redhat.com>, Scott Seago <sseago(a)redhat.com>, Michael Orazi <morazi(a)redhat.com>, jguiditt(a)redhat.com, imcleod(a)redhat.com, Hugh Brock <hbrock(a)redhat.com>, Matthew Wagner <mawagner(a)redhat.com> Gentlemen, In last couple of days, even on technical cabal, we had been dealing with following issue, which is still a little bit unclear. I would like to ask all of you for comments regarding versioning images and their component outlines. The question is: * Do we want to allow user to edit Component Outline (Image XML) which brings functionality for advanced image versioning? * And if so, on which level? Situation is following: * In Component Outline you can specify * OS (Fedora, Ubuntu, ...) * Architecture (x86_64,...) * Packages * Running services Arguments for: * User can change image specification in the future (e.g. he can add new packages, new services, etc.) * User can return back to older versions * We are adding advanced functionality for the user (giving him more freedom) * With changing just the specification, we don't have to change references in AppForm Blueprints (Deployables) since they keep still the same Image ID. Arguments against: * With changing image specification, the whole object changes (Is it still the same object with different specification? E.g. different OS, architecture,...?) * If it is still the same object, what change makes it enough different to become different one (changing OS? architecture? or what packages?) * By changing image specification we can break other dependencies in related AppForm Blueprints (Deployables), which might depend on certain package, service, etc. * If we allow Image versioning, do we also want use to use older versions of the image as well? * With more freedom becomes bigger responsibility to user and higher potential to break things down * We are complicating scenarios for user (If user wants change, he can do it by cloning image and changing just what he needs) Thank you for all of your ideas -- 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

2 1

API RFC: Information in deployable #show
by Jiří Stránský 20 Dec '12

20 Dec '12

Hi, I'd like to change some stuff in the deployments API draft and I'd like some ACKs and/or comments on the numbered issues below. I know this API already went around once in a RFC and sort of passed, but I think we missed things in there and didn't decide others. I'd like to get the implementation right so that we don't have to change it later :) The current draft is on wiki, the rest of this mail refers to this draft [1]. 1) <owner_id> *I wouldn't show owner information at all for now.* In an ideal case, this would be a proper link to a "user" resource, but we don't have API to access user information now. I think there's not much point in showing just an ID. We can add the <user> link when we have the "user" resource implemented. 2) <created_at>, <updated_at> *I wouldn't add these (yet), too.* I think our APIs, both Conductor and Tim, don't show created_at/updated_at information, even though it is available in the models. We could use <updated_at> with PUT requests to avoid concurrency issues, but I'd rather see that as a project-wide decision first, not just implement it for a few resources. So I want to leave these out to keep the APIs consistent. If we decide we want this information in APIs, we can add it across all relevant resources. 3) <global_uptime>5 minutes</global uptime> *I'll implement a standard way to serialize duration information - from XML Schema[2].* E.g. 5 minutes would serialize as "P5M". CIMI uses it as well. 4) <deployable-xml> *Should we wrap the deployable template into CDATA or not?* The benefit is that the inner XML will not be parsed by the client when parsing the API response, so an error in the template XML can't break the whole API response. And it is semantically cleaner, because the template XML won't be part of the API response XML tree, but will be treated as data, which it is. (Think if we provided JSON API, then the template XML would be treated as a data too and not converted into a corresponding JSON structure, I'd say.) The drawback is that our deployable then can't have a CDATA in it, because CDATA nesting is not allowed. For deployable templates, this might not be a problem right now, but I wonder about the future. E.g. for image templates it would be a problem [3]. So I'm sort of on the fence here, maybe a bit in favour of not wrapping it into CDATA. (Btw Tim solves this by having image template as a separate resource, but I'm not sure we should go this way for deployables as we! ll.) 5) <history> *I think this should be modelled as a separate resource/collection*, as the number of events associated with a deployment can grow limitlessly over time. CIMI has this separated too in a form of EventLog resource, though I didn't get the time to read this in detail yet. Take care, J. [1] https://redmine.aeolusproject.org/redmine/projects/aeolus/wiki/Deployments#… [2] http://www.w3.org/TR/xmlschema-2/#duration [3] https://github.com/aeolus-incubator/templates/blob/master/games/BrowserQues…

6 12

[aeolus-incubator/tim] 2967e9: Added methods for returning imgfac request data
by Jason Guiditta 19 Dec '12

19 Dec '12

Branch: refs/heads/master Home: https://github.com/aeolus-incubator/tim Commit: 2967e9581ec3e86e3ef3745d4e44e5c4ad699f42 https://github.com/aeolus-incubator/tim/commit/2967e9581ec3e86e3ef3745d4e44… Author: Martyn Taylor <mtaylor(a)redhat.com> Date: 2012-12-19 (Wed, 19 Dec 2012) Changed paths: M app/models/tim/provider_image.rb Log Message: ----------- Added methods for returning imgfac request data Added methods for returning provider account and provider information. These methods can then be easily overridden to generate this data from other sources such as Conductor ProviderAccount. Commit: 2eba454103548afbac8a47d7b3711ea0dd66aaef https://github.com/aeolus-incubator/tim/commit/2eba454103548afbac8a47d7b371… Author: jguiditta <jguiditt(a)redhat.com> Date: 2012-12-19 (Wed, 19 Dec 2012) Changed paths: M app/models/tim/provider_image.rb Log Message: ----------- Merge pull request #92 from mtaylor/add_factory_provider_info_methods Added methods for returning imgfac request data Compare: https://github.com/aeolus-incubator/tim/compare/17f31d3123ef...2eba45410354

1 0

Happy xmas and new year!
by Martyn Taylor 19 Dec '12

19 Dec '12

Gentlemen, I will be taking PTO for the rest of this year. I hope you all enjoy the xmas period and have a happy new year. See you all in 2013. Best Wishes Martyn

1 0

For anyone interested in the Conductor permissions UIs
by Jeremy Perry 19 Dec '12

19 Dec '12

Hi folks, Some of you will recall the ideas I presented at the recent Brno development conference. Today I posted a significant update of this work on the blog. I appreciate any questions or feedback you may have. http://blog.aeolusproject.org/improving-the-user-experience-for-roles-and-p… Jeremy

3 4

Aeolus-GUI Task Completed
by nitesh narayan lal 19 Dec '12

19 Dec '12

Hi, As probably some of you might be knowing that I had added a task in GCI about making a documentation for setting up of Aeolus-GUI and its been successfully completed by ____ He has done a great work and if he's interested he may continue his contribution . Documentation: https://fedoraproject.org/wiki/User:Glados/Aeolus Task On Melange:http://www.google-melange.com/gci/task/view/google/gci2012/8011222: A big thanks to GLaDOS for taking up the task and completing it successfully , I am looking forward for his further involvement in the aeolusproject if not possible right now then may be at later stages . Regards Nitesh Narayan Lal

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

aeolus-devel December 2012