aeolus-devel November 2012

aeolus-devel@lists.fedorahosted.org

48 participants
85 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

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

RFC: API versioning
by Richard Su 18 Dec '12

18 Dec '12

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_and… 4. http://railscasts.com/episodes/350-rest-api-versioning

5 7

[PATCH] Added basic support for Virtio in Windows guests in Oz.
by Luis Fernandez Alvarez 11 Dec '12

11 Dec '12

The Windows VirtIO Drivers allows Microsoft Windows guests to be installed using virtio devices. In order to make Oz support this case, it's proposed to modify the class Windows.py to get the diskbus and nicmodel from the configuration file. The performance boost installing Microsoft Windows guests is remarkable. --- oz/Windows.py | 12 ++++++++++-- 1 files changed, 10 insertions(+), 2 deletions(-) diff --git a/oz/Windows.py b/oz/Windows.py index ddc3e7f..ee4a266 100644 --- a/oz/Windows.py +++ b/oz/Windows.py @@ -33,8 +33,16 @@ class Windows(oz.Guest.CDGuest): Shared Windows base class. """ def __init__(self, tdl, config, output_disk): - oz.Guest.CDGuest.__init__(self, tdl, config, output_disk, "rtl8139", - "localtime", "usb", None, True, False) + diskbus = oz.ozutil.config_get_key(config, + 'libvirt', + 'diskbus', + 'ide') + nicmodel = oz.ozutil.config_get_key(config, + 'libvirt', + 'nicmodel', + 'rtl8139') + oz.Guest.CDGuest.__init__(self, tdl, config, output_disk, nicmodel, + "localtime", "usb", diskbus, True, False) if self.tdl.key is None: raise oz.OzException.OzException("A key is required when installing Windows") -- 1.7.1

4 6

RFC: Navigation restructuring
by Jaromir Coufal 10 Dec '12

10 Dec '12

Good morning/afternoon/evening to all (you can choose your time-zone) On our Aeolus Developer Conference I introduced new concept of Conductor UI. When I wanted to use versioning to distinguish it from current one, I realized that it would be better just to call it "new generation" :) With this e-mail I would like to follow up with more details to the first stage of our change - navigation restructuring. ==== Goals ==== - Make user oriented in the system - Allow user to quick navigate through the system - Show to user as much as possible within at least steps as possible (but don't overwhelm him) - Don't get user lost (at least not easily) - If user gets lost recover him fast ===== Solution ===== -> Two level navigation * First tier = logical grouping of elements * Second tier = elements themselves in sections (all of them) - User always knows where he is (always highlighted item in 1st and 2nd tier). - Just by 3 clicks (listing through 1st tier), user can overview all accessible sections. - It takes just 2 clicks to get to any full list of elements (e.g. list of Images) - It takes just 3 clicks to get to any detail of any element in the system. (e.g. detail of an Image) - If user looks for some section, he knows he can always find it in 2nd tier (nowhere else). ====== Structure ====== *Cloud Environments* (everything related to active content) - Overview - Cloud Environments - Resource Zones - AppForms *Catalog* (everything related to passive content) - Catalogs - AppForm Outlines - Images - Hardware Profiles *Cloud providers* - Cloud Providers - Accounts - Realms - Provider Selection - (Cost Estimates) *Users* - User groups - Users - Permissions ===== Concept ===== - *Dashboard* will not be part of navigation. It is specific page with purpose to inform user about current state of system and what happened when he was out. User will mostly work with this page just after logging in not during further use of our system. This means, that Dashboard will be a launch (home) page right after login. It is common and very widely used usability feature, that logo brings you to homepage; in our case it wouldn't be different, logo will bring you back to Dashboard. - Under each item from the second tier is list of all its elements in table view - There is one exception - first page of Cloud Environemnts = Overview (currently will be substituted by Monitor page) ========== Implementation ========== Currently we are missing following table views: - Cloud Environments - Resource Zones - AppForms - AppForm Outlines - Provider Accounts - Provider Selection Other views are already implemented, so we can just relocate them with very small adjustments. (Details in link below Summary section) ====== Summary ====== Here is summary of the whole restructuring: http://conductor.jaromircoufal.cz/new_conductor-ui_navigation-restructuring… Here is image for preview of the structure: http://conductor.jaromircoufal.cz/conductor_overview.png If you made it this far, I would be really thankful to any reaction - positive, negative, suggestions, if it makes sense to you, everything is really welcome. Looking forward to hearing from you -- 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

4 14

RFC: The case for a default username/password
by Aaron Weitekamp 05 Dec '12

05 Dec '12

I understand this is ultimately a sysadmin responsibility, but is there any scenario where a user would use the default username and password? If defaults are for developer and testing convenience it seems we can take the extra step to put our own values in. Given the serious security concerns of leaving defaults in place, I'm wondering why would we provide the option to use a default username/password? -Aaron -- Aaron Weitekamp | Red Hat CloudForms Integration QE | IRC: aweiteka

5 8

Technical Cabal Meeting Minutes 2012Nov27
by Greg Blomquist 04 Dec '12

04 Dec '12

http://openetherpad.org/AeolusTechnicalCabalMinutes-2012Nov27 I included a link to the google hangout recording. However, we abandoned the google hangout about 20 min into the meeting due to various hardware problems. We continued the meeting over a conference call (but I don't believe that was recorded). I think future meetings of the Tech Cabal will be held via recorded phone conference. We'll post the audio of those meetings.

2 2

dev-tools as non-root
by Giulio Fidente 04 Dec '12

04 Dec '12

hi there, as per subject, I made some changes to dev-tools to make it work successfully as non-root. I tested these changes on CentOS6 and F17, my pull request: https://github.com/aeolus-incubator/dev-tools/pull/7 it also includes some changes to README.md as it now provides a list of packages to be installed system-wide before launching the script. I thought launching as non-root was useful to both end users and devs cause it helps with the testing, isolation from the other system components, deploying of more versions in parallel and also provides some abstraction from the hosting distro. Feedback is very much appreciated. -- Giulio Fidente

3 5

Status of pull requests for end of current sprint
by steve linabery 30 Nov '12

30 Nov '12

Hi all, I'm looking at github conductor and seeing a large number of open issues with the current sprint as the milestone[1] Am I looking at this the wrong way, or does everybody need to take another look at the pull requests and make sure things there reflect reality? In any case, I am looking to tag our components' repos Friday morning. I was going to do it now, but I want to make sure we are ready. TIA, Steve|eggs [1]https://github.com/aeolusproject/conductor/issues?milestone=1&page=1&stat…

1 1

RFC: race condition in resource updates
by Richard Su 30 Nov '12

30 Nov '12

Hi, There is a race condition when two clients attempt to update the same resource at the same time. Both clients sees the same initial state. Client A changes it to state A and then Client B changes it to state B. Client B should know that the resource was changed to state A before deciding whether to change the state to B. This race condition is present in both the UI and API. If we want to prevent this type of race condition, there are two ways to solve it: one leaves it optional and the other forces the prevention. The optional case, uses headers, and leaves the decision to prevent such race conditions to the client. The forced case uses the updated_at field as a means to check if a resource has been modified. It is not clear to me if it should be forced since the UI currently allows it whether by design or oversight. Your opinion on this matter is appreciated. * Optional Case Use the ETag header, containing a MD5 hash, to indicate the state of the resource. As far as I can tell we have this header already, perhaps it is auto generated. In a PUT, clients will include a If-Match header as part of the request, setting the value to the ETag hash it received when it last received the resource's state. Before processing a PUT, the server will compare ETag to If-Match and allow the request to complete if the values match. If the values do not match the server returns status code 412 - Precondition Failed. A time based alternative to ETag and If-Match would be Last-Modified and If-Unmodified-Since. This does not address the issue for the UI. (This idea is from http://blog.m.artins.net/restful-web-services-preventing-race-conditions/) * Forced Case Most of the resources available through the api have a updated_at field. One exception is deployables, and this will need to be rectified. The updated_at field can be used as a timestamp to flag an error if a resource has changed since the client last requested a view of it. For the API, in a PUT, clients will be required to return back the updated_at value. If the server sees updated_at has not changed, the request is allowed to complete. If the value has changed, the server returns status 409 - Conflict. For the UI, we can embed updated_at as hidden form data and perform the same comparisons. If a change is detected, the server will display an error message.

4 6

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

aeolus-devel November 2012