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
I hope we will get it soon implemented and start real user testing (you
Red Hat Czech s.r.o.
Mobile: +420 724 595 508
IRC: jcoufal at #cloudforms-ui, #aeolus, #brno
We have slowly-developing upstream repo of image templates for the existing
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,
Aeolus Cloud Evangelist
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!
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:
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)