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
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.
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 .
*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.* E.g. 5 minutes would serialize as "P5M". CIMI uses it as well.
*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 . 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!
*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.
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.
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?
Resources I found useful:
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
@@ -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,
+ nicmodel = oz.ozutil.config_get_key(config,
+ 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")
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.
- 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
-> 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
- Just by 3 clicks (listing through 1st tier), user can overview all
- It takes just 2 clicks to get to any full list of elements (e.g. list
- 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).
(everything related to active content)
- Cloud Environments
- Resource Zones
(everything related to passive content)
- AppForm Outlines
- Hardware Profiles
- Cloud Providers
- Provider Selection
- (Cost Estimates)
- User groups
- *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
- There is one exception - first page of Cloud Environemnts = Overview
(currently will be substituted by Monitor page)
Currently we are missing following table views:
- Cloud Environments
- Resource Zones
- 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)
Here is summary of the whole restructuring:
Here is image for preview of the structure:
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
Looking forward to hearing from you
Red Hat Czech s.r.o.
Mobile: +420 724 595 508
IRC: jcoufal at #cloudforms-ui, #aeolus, #brno
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 Weitekamp | Red Hat CloudForms Integration QE | IRC: aweiteka
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
I think future meetings of the Tech Cabal will be held via recorded phone
conference. We'll post the audio of those meetings.
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:
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.
I'm looking at github conductor and seeing a large number of open issues with the current sprint as the milestone
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.
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
* 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
* 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