moving wiki content
by Mo Morsi
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
10 years, 5 months
quickly developing / testing tdl's
by Mo Morsi
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
10 years, 10 months
State Transitions in ReST API
by Martyn Taylor
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
10 years, 11 months
Sprint review screencasts
by Jirka Tomasek
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.
10 years, 11 months
Fwd: RFC: Image versioning / Component Outline versioning
by Jaromir Coufal
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
10 years, 11 months
API RFC: Information in deployable #show
by Jiří Stránský
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/Deployment...
[2] http://www.w3.org/TR/xmlschema-2/#duration
[3] https://github.com/aeolus-incubator/templates/blob/master/games/BrowserQu...
10 years, 11 months
Happy xmas and new year!
by Martyn Taylor
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
10 years, 11 months