Hi guys,
I've been following the Aeolus Community Assessment conversation and I though I might start a separate e-mail chain regarding an idea I had instead of railroading the original conversation.
From what I saw of the original conversation, we're looking to build our community and evangelize Aeolus' strengths.
It's also been questioned as whether we'd recommend using Aeolus in it's current state in a production environment. This got me thinking... there's a difference between what we'd recommend to users, and what they'll actually do. By this, I mean that there might be a boffin or two somewhere who could devise some unique uses for Aeolus that we've never even thought of. And I think that what some might consider Aeolus's biggest weakness (it's still experimental) could end up being its biggest strength (experimental is fun and exciting!).
My proposal -----------
We develop our own (for lack of a better word) "Apps Store" -- a place when users can share Image and Deployable templates for Aeolus, much along the same lines as addons.mozilla.org or extensions.gnome.org. And following these subdomain conventions, I suggest... templates.aeolusproject.org!
How it works ------------
A user writes an image template and deployable for a particular application. For example, they might want to launch a base Drupal installation in EC2 using Fedora as an OS. So they write an Image Template that includes the relevant Apache and Postgres packages. They also write a Deployable Template that installs and configures Drupal (via Audrey) to an instance with httpd/db.
Then the user thinks, "Hey, I bet there are others out there who want to install Drupal in the cloud. Maybe I should share these templates with the world."
The user uploads the templates to templates.aeolusproject.org, tags them as an Image Template and Deployable Template respectively, and create an associates between the two (basically a way of signifying a relationship between an image/deployable pair that works well together).
So then, I want to create a Drupal site on a standalone instance in my own RHEV environment.
I search templates.aeolusproject.org and find someone has already created the templates I need. Perfect. (Plus I could substitute the Image template for one with a different distro if I prefer).
I use both these template in Aeolus and install Drupal on EC2. It works great!
I go back to templates.aeolusproject.org and give the template author a 5-star rating. Great job, everything went better than expected. Plus, the rating helps his Deployable Template becomes TOTM (Template of the Month).
But I also leave a comment to say, "Hey, great templates, but I think you should include a param in the deployable that allows a user to input a comma-separated list of additional modules for their Drupal installation." This way I'm helping improve the content of templates.aeolusproject.org through feedback.
Benefits --------
templates.aeolusproject.org does a couple of cool things:
1. Encourages people to join, contribute and collaborate to the Aeolus community 2. Encourages people to experiment with Aeolus and share their results 3. Helps new users wanting to learn more about TDL/Deployable XML 4. Provides users with a library of applications to launch into their cloud (and only needing two XML files to do so) 5. Gives us a better idea of how people are using Aeolus so that we can enhance the features they like and improve the features they don't like
These are very rough ideas that I've come up with in a day, so please forgive me if they seem a little ill-thought. Regardless, I do think is an idea that can really enhance the Aeolus Community and the project too. If anyone has an ideas, suggestions, drawbacks or general comments, please share them.
Dan Macpherson Content Author Engineering Content Services Red Hat Asia Pacific Pty Ltd Brisbane, Australia
e: dmacpher@redhat.com
Sounds a whole lot like http://www.susegallery.com
Some thoughts: Firstly; there is a serious financial cost to hosting something like this which is probably why we aren't attempting it. Secondly; It's actually an excellent idea to bring other open source projects and software products in on our development process (as stakeholders) and it would give us boatloads of handy analytical metrics for what customers are seeking / what aspects they are utilising…. I don't know that we'll ever get to this place unless “sugardaddy shadowman” grants us the both the financial means and a strategic green light for both infrastructure and development time. IMHO a central online ecosystem for templates would be the absolute best way to foster community growth but there are more barriers than other tactics.
TL;DR Something similar has being done, we can't afford / don't want to do it for ourselves ….(yet)
Andy
On 08/06/2012, at 2:47 PM, Dan Macpherson wrote:
Hi guys,
I've been following the Aeolus Community Assessment conversation and I though I might start a separate e-mail chain regarding an idea I had instead of railroading the original conversation.
From what I saw of the original conversation, we're looking to build our community and evangelize Aeolus' strengths.
It's also been questioned as whether we'd recommend using Aeolus in it's current state in a production environment. This got me thinking... there's a difference between what we'd recommend to users, and what they'll actually do. By this, I mean that there might be a boffin or two somewhere who could devise some unique uses for Aeolus that we've never even thought of. And I think that what some might consider Aeolus's biggest weakness (it's still experimental) could end up being its biggest strength (experimental is fun and exciting!).
My proposal
We develop our own (for lack of a better word) "Apps Store" -- a place when users can share Image and Deployable templates for Aeolus, much along the same lines as addons.mozilla.org or extensions.gnome.org. And following these subdomain conventions, I suggest... templates.aeolusproject.org!
How it works
A user writes an image template and deployable for a particular application. For example, they might want to launch a base Drupal installation in EC2 using Fedora as an OS. So they write an Image Template that includes the relevant Apache and Postgres packages. They also write a Deployable Template that installs and configures Drupal (via Audrey) to an instance with httpd/db.
Then the user thinks, "Hey, I bet there are others out there who want to install Drupal in the cloud. Maybe I should share these templates with the world."
The user uploads the templates to templates.aeolusproject.org, tags them as an Image Template and Deployable Template respectively, and create an associates between the two (basically a way of signifying a relationship between an image/deployable pair that works well together).
So then, I want to create a Drupal site on a standalone instance in my own RHEV environment.
I search templates.aeolusproject.org and find someone has already created the templates I need. Perfect. (Plus I could substitute the Image template for one with a different distro if I prefer).
I use both these template in Aeolus and install Drupal on EC2. It works great!
I go back to templates.aeolusproject.org and give the template author a 5-star rating. Great job, everything went better than expected. Plus, the rating helps his Deployable Template becomes TOTM (Template of the Month).
But I also leave a comment to say, "Hey, great templates, but I think you should include a param in the deployable that allows a user to input a comma-separated list of additional modules for their Drupal installation." This way I'm helping improve the content of templates.aeolusproject.org through feedback.
Benefits
templates.aeolusproject.org does a couple of cool things:
- Encourages people to join, contribute and collaborate to the Aeolus community
- Encourages people to experiment with Aeolus and share their results
- Helps new users wanting to learn more about TDL/Deployable XML
- Provides users with a library of applications to launch into their cloud (and only needing two XML files to do so)
- Gives us a better idea of how people are using Aeolus so that we can enhance the features they like and improve the features they don't like
These are very rough ideas that I've come up with in a day, so please forgive me if they seem a little ill-thought. Regardless, I do think is an idea that can really enhance the Aeolus Community and the project too. If anyone has an ideas, suggestions, drawbacks or general comments, please share them.
Dan Macpherson Content Author Engineering Content Services Red Hat Asia Pacific Pty Ltd Brisbane, Australia
e: dmacpher@redhat.com
On 06/08/2012 06:47 AM, Dan Macpherson wrote:
Hi guys,
I've been following the Aeolus Community Assessment conversation and I though I might start a separate e-mail chain regarding an idea I had instead of railroading the original conversation.
From what I saw of the original conversation, we're looking to build our community and evangelize Aeolus' strengths.
It's also been questioned as whether we'd recommend using Aeolus in it's current state in a production environment. This got me thinking... there's a difference between what we'd recommend to users, and what they'll actually do. By this, I mean that there might be a boffin or two somewhere who could devise some unique uses for Aeolus that we've never even thought of. And I think that what some might consider Aeolus's biggest weakness (it's still experimental) could end up being its biggest strength (experimental is fun and exciting!).
My proposal -----------
We develop our own (for lack of a better word) "Apps Store" -- a place when users can share Image and Deployable templates for Aeolus, much along the same lines as addons.mozilla.org or extensions.gnome.org. And following these subdomain conventions, I suggest... templates.aeolusproject.org!
How it works ------------
A user writes an image template and deployable for a particular application. For example, they might want to launch a base Drupal installation in EC2 using Fedora as an OS. So they write an Image Template that includes the relevant Apache and Postgres packages. They also write a Deployable Template that installs and configures Drupal (via Audrey) to an instance with httpd/db.
Then the user thinks, "Hey, I bet there are others out there who want to install Drupal in the cloud. Maybe I should share these templates with the world."
The user uploads the templates to templates.aeolusproject.org, tags them as an Image Template and Deployable Template respectively, and create an associates between the two (basically a way of signifying a relationship between an image/deployable pair that works well together).
So then, I want to create a Drupal site on a standalone instance in my own RHEV environment.
I search templates.aeolusproject.org and find someone has already created the templates I need. Perfect. (Plus I could substitute the Image template for one with a different distro if I prefer).
I use both these template in Aeolus and install Drupal on EC2. It works great!
I go back to templates.aeolusproject.org and give the template author a 5-star rating. Great job, everything went better than expected. Plus, the rating helps his Deployable Template becomes TOTM (Template of the Month).
But I also leave a comment to say, "Hey, great templates, but I think you should include a param in the deployable that allows a user to input a comma-separated list of additional modules for their Drupal installation." This way I'm helping improve the content of templates.aeolusproject.org through feedback.
Benefits --------
templates.aeolusproject.org does a couple of cool things:
- Encourages people to join, contribute and collaborate to the
Aeolus community 2. Encourages people to experiment with Aeolus and share their results 3. Helps new users wanting to learn more about TDL/Deployable XML 4. Provides users with a library of applications to launch into their cloud (and only needing two XML files to do so) 5. Gives us a better idea of how people are using Aeolus so that we can enhance the features they like and improve the features they don't like
These are very rough ideas that I've come up with in a day, so please forgive me if they seem a little ill-thought. Regardless, I do think is an idea that can really enhance the Aeolus Community and the project too. If anyone has an ideas, suggestions, drawbacks or general comments, please share them.
Dan Macpherson Content Author Engineering Content Services Red Hat Asia Pacific Pty Ltd Brisbane, Australia
e: dmacpher@redhat.com
+1 to this idea
Jan
On 06/08/2012 06:47 AM, Dan Macpherson wrote:
Hi guys,
I've been following the Aeolus Community Assessment conversation and I though I might start a separate e-mail chain regarding an idea I had instead of railroading the original conversation.
From what I saw of the original conversation, we're looking to build our community and evangelize Aeolus' strengths.
It's also been questioned as whether we'd recommend using Aeolus in it's current state in a production environment. This got me thinking... there's a difference between what we'd recommend to users, and what they'll actually do. By this, I mean that there might be a boffin or two somewhere who could devise some unique uses for Aeolus that we've never even thought of. And I think that what some might consider Aeolus's biggest weakness (it's still experimental) could end up being its biggest strength (experimental is fun and exciting!).
My proposal
We develop our own (for lack of a better word) "Apps Store" -- a place when users can share Image and Deployable templates for Aeolus, much along the same lines as addons.mozilla.org or extensions.gnome.org. And following these subdomain conventions, I suggest... templates.aeolusproject.org!
How it works
A user writes an image template and deployable for a particular application. For example, they might want to launch a base Drupal installation in EC2 using Fedora as an OS. So they write an Image Template that includes the relevant Apache and Postgres packages. They also write a Deployable Template that installs and configures Drupal (via Audrey) to an instance with httpd/db.
Then the user thinks, "Hey, I bet there are others out there who want to install Drupal in the cloud. Maybe I should share these templates with the world."
The user uploads the templates to templates.aeolusproject.org, tags them as an Image Template and Deployable Template respectively, and create an associates between the two (basically a way of signifying a relationship between an image/deployable pair that works well together).
So then, I want to create a Drupal site on a standalone instance in my own RHEV environment.
I search templates.aeolusproject.org and find someone has already created the templates I need. Perfect. (Plus I could substitute the Image template for one with a different distro if I prefer).
I use both these template in Aeolus and install Drupal on EC2. It works great!
I go back to templates.aeolusproject.org and give the template author a 5-star rating. Great job, everything went better than expected. Plus, the rating helps his Deployable Template becomes TOTM (Template of the Month).
But I also leave a comment to say, "Hey, great templates, but I think you should include a param in the deployable that allows a user to input a comma-separated list of additional modules for their Drupal installation." This way I'm helping improve the content of templates.aeolusproject.org through feedback.
Benefits
templates.aeolusproject.org does a couple of cool things:
- Encourages people to join, contribute and collaborate to the Aeolus community
- Encourages people to experiment with Aeolus and share their results
- Helps new users wanting to learn more about TDL/Deployable XML
- Provides users with a library of applications to launch into their cloud (and only needing two XML files to do so)
- Gives us a better idea of how people are using Aeolus so that we can enhance the features they like and improve the features they don't like
These are very rough ideas that I've come up with in a day, so please forgive me if they seem a little ill-thought. Regardless, I do think is an idea that can really enhance the Aeolus Community and the project too. If anyone has an ideas, suggestions, drawbacks or general comments, please share them.
Dan Macpherson Content Author Engineering Content Services Red Hat Asia Pacific Pty Ltd Brisbane, Australia
e: dmacpher@redhat.com
Shameless self promotion, but the Snap tool [1] that I've been sporadically working on has the ability to generate TDL's from a running cloud instance. I could easily add the ability to tie this to this site, where a user can automatically upload a TDL corresponding to an instance they have running on the cloud.
-Mo
On 08/06/2012, at 5:46 PM, Mo Morsi wrote: <snip>
Shameless self promotion, but the Snap tool [1] that I've been sporadically working on has the ability to generate TDL's from a running cloud instance. I could easily add the ability to tie this to this site, where a user can automatically upload a TDL corresponding to an instance they have running on the cloud.
Curiosity question... how does Snap handle old package versions and manual customisations?
For (rough) example, if a cloud instance was originally built using ancient versions of packages, plus someone logged into it post build to make manual changes.
Would the version "rebuilt" from Snap's TDL of it have the manual changes, and would it want to use the same ancient package versions? (or would it go for newer versions?)
:)
+ Justin
-- Aeolus Community Manager http://www.aeolusproject.org
On 06/20/2012 11:05 AM, Justin Clift wrote:
On 08/06/2012, at 5:46 PM, Mo Morsi wrote:
<snip> > Shameless self promotion, but the Snap tool [1] that I've been > sporadically working on has the ability to generate TDL's from a running > cloud instance. I could easily add the ability to tie this to this site, > where a user can automatically upload a TDL corresponding to an instance > they have running on the cloud. Curiosity question... how does Snap handle old package versions and manual customisations?
For (rough) example, if a cloud instance was originally built using ancient versions of packages, plus someone logged into it post build to make manual changes.
Would the version "rebuilt" from Snap's TDL of it have the manual changes, and would it want to use the same ancient package versions? (or would it go for newer versions?)
:)
- Justin
-- Aeolus Community Manager http://www.aeolusproject.org
The way snap currently works is it stores the packages that are installed with their versions and anything which has been modified post-installation.
When restoring the snapshot, whichever is the latest version of the package in the available repos at the time is used. The version of the package that is stored in the snapshot isn't used during the restoration process. Though it would be fairly easy to add the capability to give preference to that version when restoring the package if we wanted.
-Mo
On Friday, June 08, 2012 12:47:30 AM Dan Macpherson wrote:
Hi guys,
I've been following the Aeolus Community Assessment conversation and I though I might start a separate e-mail chain regarding an idea I had instead of railroading the original conversation.
From what I saw of the original conversation, we're looking to build our community and evangelize Aeolus' strengths.
It's also been questioned as whether we'd recommend using Aeolus in it's current state in a production environment. This got me thinking... there's a difference between what we'd recommend to users, and what they'll actually do. By this, I mean that there might be a boffin or two somewhere who could devise some unique uses for Aeolus that we've never even thought of. And I think that what some might consider Aeolus's biggest weakness (it's still experimental) could end up being its biggest strength (experimental is fun and exciting!).
My proposal
We develop our own (for lack of a better word) "Apps Store" -- a place when users can share Image and Deployable templates for Aeolus, much along the same lines as addons.mozilla.org or extensions.gnome.org. And following these subdomain conventions, I suggest... templates.aeolusproject.org!
How it works
A user writes an image template and deployable for a particular application. For example, they might want to launch a base Drupal installation in EC2 using Fedora as an OS. So they write an Image Template that includes the relevant Apache and Postgres packages. They also write a Deployable Template that installs and configures Drupal (via Audrey) to an instance with httpd/db.
Then the user thinks, "Hey, I bet there are others out there who want to install Drupal in the cloud. Maybe I should share these templates with the world."
The user uploads the templates to templates.aeolusproject.org, tags them as an Image Template and Deployable Template respectively, and create an associates between the two (basically a way of signifying a relationship between an image/deployable pair that works well together).
So then, I want to create a Drupal site on a standalone instance in my own RHEV environment.
I search templates.aeolusproject.org and find someone has already created the templates I need. Perfect. (Plus I could substitute the Image template for one with a different distro if I prefer).
I use both these template in Aeolus and install Drupal on EC2. It works great!
I go back to templates.aeolusproject.org and give the template author a 5-star rating. Great job, everything went better than expected. Plus, the rating helps his Deployable Template becomes TOTM (Template of the Month).
But I also leave a comment to say, "Hey, great templates, but I think you should include a param in the deployable that allows a user to input a comma-separated list of additional modules for their Drupal installation." This way I'm helping improve the content of templates.aeolusproject.org through feedback.
Benefits
templates.aeolusproject.org does a couple of cool things:
- Encourages people to join, contribute and collaborate to the Aeolus community
- Encourages people to experiment with Aeolus and share their results
- Helps new users wanting to learn more about TDL/Deployable XML
- Provides users with a library of applications to launch into their cloud (and only needing two XML files to do so)
- Gives us a better idea of how people are using Aeolus so that we can enhance the features they like and improve the features they don't like
These are very rough ideas that I've come up with in a day, so please forgive me if they seem a little ill-thought. Regardless, I do think is an idea that can really enhance the Aeolus Community and the project too. If anyone has an ideas, suggestions, drawbacks or general comments, please share them.
Dan Macpherson Content Author Engineering Content Services Red Hat Asia Pacific Pty Ltd Brisbane, Australia
e: dmacpher@redhat.com
+1 Interesting idea...
Missing from list (used wrong email) / /
On 08/06/2012, at 4:15 PM, Dan Macpherson dmacpher@redhat.com wrote:
----- Original Message -----
Sounds a whole lot like http://www.susegallery.com
Similar, yes.
Some thoughts: Firstly; there is a serious financial cost to hosting something like this which is probably why we aren't attempting it.
True, it does come down to the $$$, but if it's in the name of building Aeolus' reputation and enhancing the community, I'd consider it more of an investment than a cost. Plus, this feeds into my next point...
Secondly; It's actually an excellent idea to bring other open source projects and software products in on our development process (as stakeholders) and it would give us boatloads of handy analytical metrics for what customers are seeking / what aspects they are utilising….
Exactly. I'd like to eventually see cross-overs with other communities/organizations in terms of:
Linux groups (Fedora, Ubuntu, Mint, Arch, etc) release basic image template types for Aeolus
Open source projects release image and deployable templates for their applications. For example, CMS groups release deployables for basic Drupal, Joomla, Wordpress, etc installs
Red Hat releases templates for an uber-JBoss App Server Stack running on RHEL than you can easily launch on your private RHEV cloud and automagically connect with RHN or distribution proxies (Satellite, SAM, System Engine, etc)
Other commercial enterprises join in, design Aelous templates for users wanting to easily launch their app into a cloud.
While points 1 + 2 are goals to help us build our community, 3 + 4 are the goals to make the project financially worthwhile because there's an enterprise interest in template creation.
And like I said previously, there might be things that users/organizations can do with Aeolus beyond points 1-4.
Thanks, Andy! Someday I'll learn the difference between "Reply" and "Reply to All". :)
Dan Macpherson Content Author Engineering Content Services Red Hat Asia Pacific Pty Ltd Brisbane, Australia
e: dmacpher@redhat.com
----- Andrew Fitzsimon afitzsim@redhat.com wrote:
Missing from list (used wrong email) / /
On 08/06/2012, at 4:15 PM, Dan Macpherson dmacpher@redhat.com wrote:
----- Original Message -----
Sounds a whole lot like http://www.susegallery.com
Similar, yes.
Some thoughts: Firstly; there is a serious financial cost to hosting something like this which is probably why we aren't attempting it.
True, it does come down to the $$$, but if it's in the name of building Aeolus' reputation and enhancing the community, I'd consider it more of an investment than a cost. Plus, this feeds into my next point...
Secondly; It's actually an excellent idea to bring other open source projects and software products in on our development process (as stakeholders) and it would give us boatloads of handy analytical metrics for what customers are seeking / what aspects they are utilising….
Exactly. I'd like to eventually see cross-overs with other communities/organizations in terms of:
Linux groups (Fedora, Ubuntu, Mint, Arch, etc) release basic image template types for Aeolus
Open source projects release image and deployable templates for their applications. For example, CMS groups release deployables for basic Drupal, Joomla, Wordpress, etc installs
Red Hat releases templates for an uber-JBoss App Server Stack running on RHEL than you can easily launch on your private RHEV cloud and automagically connect with RHN or distribution proxies (Satellite, SAM, System Engine, etc)
Other commercial enterprises join in, design Aelous templates for users wanting to easily launch their app into a cloud.
While points 1 + 2 are goals to help us build our community, 3 + 4 are the goals to make the project financially worthwhile because there's an enterprise interest in template creation.
And like I said previously, there might be things that users/organizations can do with Aeolus beyond points 1-4.
On Fri, Jun 08, 2012 at 06:21:41AM -0400, Andrew Fitzsimon wrote:
Some thoughts: Firstly; there is a serious financial cost to hosting something like this which is probably why we aren't attempting it.
True, it does come down to the $$$, but if it's in the name of building Aeolus' reputation and enhancing the community, I'd consider it more of an investment than a cost. Plus, this feeds into my next point...
If we just distributed the _templates_, versus built images, I'd expect the bandwidth costs to be minimal. Download the template, customize to your liking, and build!
(The other advantage of doing that is that we don't have to worry about updates -- if your template points to the packages in appropriate repos, once you build it, you'd have the latest.)
Secondly; It's actually an excellent idea to bring other open source projects and software products in on our development process (as stakeholders) and it would give us boatloads of handy analytical metrics for what customers are seeking / what aspects they are utilising….
Exactly. I'd like to eventually see cross-overs with other communities/organizations in terms of:
Linux groups (Fedora, Ubuntu, Mint, Arch, etc) release basic image template types for Aeolus
Open source projects release image and deployable templates for their applications. For example, CMS groups release deployables for basic Drupal, Joomla, Wordpress, etc installs
Slightly random, but this also makes me think... A ton of templates for those things already exist in Amazon's marketplace. We could perhaps link to them to allow import? (But then it's EC2-only.)
Dan, overall, I'm loving this idea! I think it might need a little bit of thinking on how to make it work technically, but it's an awesome idea!
-- Matt
On Fri, Jun 08, 2012 at 08:59:43AM -0400, Matt Wagner wrote:
On Fri, Jun 08, 2012 at 06:21:41AM -0400, Andrew Fitzsimon wrote:
Some thoughts: Firstly; there is a serious financial cost to hosting something like this which is probably why we aren't attempting it.
True, it does come down to the $$$, but if it's in the name of building Aeolus' reputation and enhancing the community, I'd consider it more of an investment than a cost. Plus, this feeds into my next point...
If we just distributed the _templates_, versus built images, I'd expect the bandwidth costs to be minimal. Download the template, customize to your liking, and build!
(The other advantage of doing that is that we don't have to worry about updates -- if your template points to the packages in appropriate repos, once you build it, you'd have the latest.)
Secondly; It's actually an excellent idea to bring other open source projects and software products in on our development process (as stakeholders) and it would give us boatloads of handy analytical metrics for what customers are seeking / what aspects they are utilising….
Exactly. I'd like to eventually see cross-overs with other communities/organizations in terms of:
Linux groups (Fedora, Ubuntu, Mint, Arch, etc) release basic image template types for Aeolus
Open source projects release image and deployable templates for their applications. For example, CMS groups release deployables for basic Drupal, Joomla, Wordpress, etc installs
Slightly random, but this also makes me think... A ton of templates for those things already exist in Amazon's marketplace. We could perhaps link to them to allow import? (But then it's EC2-only.)
Dan, overall, I'm loving this idea! I think it might need a little bit of thinking on how to make it work technically, but it's an awesome idea!
Yeah. We have to do this -- it's a blindingly obvious way to generate community interest and a real benefit for users.
I've asked Francesco to head up the effort of getting the thing built. We can host it on the Redmine machine for now -- if it gets bogged down with too many users, well, that goes in the category of problems we'd like to have.
Andy Fitz, can you help with the design? I'll then appoint someone to help Francesco get it coded up.
Good stuff...
--Hugh
On 06/08/2012 09:24 AM, Hugh O. Brock wrote:
Yeah. We have to do this -- it's a blindingly obvious way to generate community interest and a real benefit for users.
I've asked Francesco to head up the effort of getting the thing built. We can host it on the Redmine machine for now -- if it gets bogged down with too many users, well, that goes in the category of problems we'd like to have.
Andy Fitz, can you help with the design? I'll then appoint someone to help Francesco get it coded up.
Good stuff...
--Hugh
I agree with everyone else here -- it is an excellent idea. It will require one change to the deployable definition (and possibly a related change to the image model) that we've discussed in the past -- this may be the actual motivator to get it done. Currently deployables reference image by UUID, which makes them completely un-shareable. For this to work we need to change the deployable definition to allow referencing images by name. Since we're sharing deployables with templates, it's actually template name we'd want to use.
There are a bunch of implementation edge cases to work through here -- since it's valid to use the same template more than once -- i.e. more than one image that happen to use the same template, the template name will not uniquely identify an image. When you take a set of templates+deployables that were shared and import/build/push the templates and then import the deployables, you could end up with a situation where a deployable identifies a template/image by a name that maps to more than one image in the system -- either because the same template has been used more than once, or because there are multiple templates that happen to have the same name. We'll have to come up with some way to resolve this, but the answer isn't obvious to me at this time.
Scott
----- Original Message -----
On 06/08/2012 09:24 AM, Hugh O. Brock wrote:
Yeah. We have to do this -- it's a blindingly obvious way to generate community interest and a real benefit for users.
I've asked Francesco to head up the effort of getting the thing built. We can host it on the Redmine machine for now -- if it gets bogged down with too many users, well, that goes in the category of problems we'd like to have.
Andy Fitz, can you help with the design? I'll then appoint someone to help Francesco get it coded up.
Good stuff...
--Hugh
I agree with everyone else here -- it is an excellent idea. It will require one change to the deployable definition (and possibly a related change to the image model) that we've discussed in the past -- this may be the actual motivator to get it done. Currently deployables reference image by UUID, which makes them completely un-shareable. For this to work we need to change the deployable definition to allow referencing images by name. Since we're sharing deployables with templates, it's actually template name we'd want to use.
It might be quite interesting to be able to refer to template via a url (real or not for now).
There are a bunch of implementation edge cases to work through here
since it's valid to use the same template more than once -- i.e. more than one image that happen to use the same template, the template name will not uniquely identify an image. When you take a set of templates+deployables that were shared and import/build/push the templates and then import the deployables, you could end up with a situation where a deployable identifies a template/image by a name that maps to more than one image in the system -- either because the same template has been used more than once, or because there are multiple templates that happen to have the same name. We'll have to come up with some way to resolve this, but the answer isn't obvious to me at this time.
Scott
On 06/08/2012 01:53 PM, Michael Orazi wrote:
----- Original Message -----
On 06/08/2012 09:24 AM, Hugh O. Brock wrote:
Yeah. We have to do this -- it's a blindingly obvious way to generate community interest and a real benefit for users.
I've asked Francesco to head up the effort of getting the thing built. We can host it on the Redmine machine for now -- if it gets bogged down with too many users, well, that goes in the category of problems we'd like to have.
Andy Fitz, can you help with the design? I'll then appoint someone to help Francesco get it coded up.
Good stuff...
--Hugh
I agree with everyone else here -- it is an excellent idea. It will require one change to the deployable definition (and possibly a related change to the image model) that we've discussed in the past -- this may be the actual motivator to get it done. Currently deployables reference image by UUID, which makes them completely un-shareable. For this to work we need to change the deployable definition to allow referencing images by name. Since we're sharing deployables with templates, it's actually template name we'd want to use.
It might be quite interesting to be able to refer to template via a url (real or not for now).
Sure. This is one case where the "portable" format may differ from what we end up with in the database once imported. With a "portable" deployable file imported into conductor, if the template is referenced by URL we'll need to pull the template into conductor at the same time, since we need it locally to build. Once that's done, the in-database representation of the deployable would then point to this imported template (by name?) rather than the URL alone, although we may also want to keep the URL around so we know where we got it -- to eventually give alerts if something is out-of-date, etc.
There are a bunch of implementation edge cases to work through here
since it's valid to use the same template more than once -- i.e. more than one image that happen to use the same template, the template name will not uniquely identify an image. When you take a set of templates+deployables that were shared and import/build/push the templates and then import the deployables, you could end up with a situation where a deployable identifies a template/image by a name that maps to more than one image in the system -- either because the same template has been used more than once, or because there are multiple templates that happen to have the same name. We'll have to come up with some way to resolve this, but the answer isn't obvious to me at this time.
Scott
So building on this,
Here's a rough architecture of pages
# Login screen * oauth: google / openid, facebook, twitter etc
# Gallery page ( default page ) * Pagination * Categories
# deployable template screen * Rating / 'liking' * Links to templates * Click to view / (edit if owner) * Download * CommentsS
# template screen * Rating * Download * Click to view textarea/ (edit if owner) * Comments * Used by ...(deployables)
# New template screen * Upload button * Edit from boilerplate in textarea
# New deployable screen * Upload button * Edit from boilerplate textarea * Select template from gallery populated list
==============================
There is some potential duplication of features here for what would make a perfect conductor start-here-page. Imagine being greeted with a screen that says:
"new template (upload/edit)" and "select from templates gallery"
the "select from templates gallery" - no idea yet on how to best present this
On 9/06/12 4:29 AM, Scott Seago wrote:
On 06/08/2012 01:53 PM, Michael Orazi wrote:
----- Original Message -----
On 06/08/2012 09:24 AM, Hugh O. Brock wrote:
Yeah. We have to do this -- it's a blindingly obvious way to generate community interest and a real benefit for users.
I've asked Francesco to head up the effort of getting the thing built. We can host it on the Redmine machine for now -- if it gets bogged down with too many users, well, that goes in the category of problems we'd like to have.
Andy Fitz, can you help with the design? I'll then appoint someone to help Francesco get it coded up.
Good stuff...
--Hugh
I agree with everyone else here -- it is an excellent idea. It will require one change to the deployable definition (and possibly a related change to the image model) that we've discussed in the past -- this may be the actual motivator to get it done. Currently deployables reference image by UUID, which makes them completely un-shareable. For this to work we need to change the deployable definition to allow referencing images by name. Since we're sharing deployables with templates, it's actually template name we'd want to use.
It might be quite interesting to be able to refer to template via a url (real or not for now).
Sure. This is one case where the "portable" format may differ from what we end up with in the database once imported. With a "portable" deployable file imported into conductor, if the template is referenced by URL we'll need to pull the template into conductor at the same time, since we need it locally to build. Once that's done, the in-database representation of the deployable would then point to this imported template (by name?) rather than the URL alone, although we may also want to keep the URL around so we know where we got it -- to eventually give alerts if something is out-of-date, etc.
There are a bunch of implementation edge cases to work through here
since it's valid to use the same template more than once -- i.e. more than one image that happen to use the same template, the template name will not uniquely identify an image. When you take a set of templates+deployables that were shared and import/build/push the templates and then import the deployables, you could end up with a situation where a deployable identifies a template/image by a name that maps to more than one image in the system -- either because the same template has been used more than once, or because there are multiple templates that happen to have the same name. We'll have to come up with some way to resolve this, but the answer isn't obvious to me at this time.
Scott
Hey all,
Andy needs feedback on his concept images.
(they're in the email prior to this one, after a bunch of text, in this thread)
+ Justin
On 12/06/2012, at 4:46 PM, Andy Fitzsimon wrote: <snip>
<heeffiif.png>
<iggbieei.png>
<daiiidgh.png>
<behgehaj.png> <chighhfg.png>
-- Aeolus Community Manager http://www.aeolusproject.org
On Tue, Jun 12, 2012 at 04:46:36PM +1000, Andy Fitzsimon wrote:
So building on this,
Here's a rough architecture of pages
Sorry for not responding sooner. I've been kind of eagerly awaiting your response, and Justin's reply made me realize that it's been sitting in my mailbox for a week. :-[
# Login screen
- oauth: google / openid, facebook, twitter etc
As a login screen, I think this is good.
The placement in this set sort of implies that you need to log in before you can do anything. I had kind of imagined that 95% of people would "just" grab a template, and only 5% of users would actually create any. So I think requiring login for normal operation would just be a barrier to entry. (I'm not sure if you're actually suggesting that they should have to log in before downloading templates and whatnot, though.)
Can you actually use GitHub as a login source? That would be neat!
# Gallery page ( default page )
- Pagination
- Categories
I like the graphic for single image versus multi-image deployables.
By "Categories", do you mean the Newest/Popular/Highest-Rated sort of categories you show, or do you also envision a more hierarchical layout, e.g., "Web apps", "Financial apps", "Game servers", etc.? (Those are terrible categories on my part, but you get the idea.)
My fear here is that, initially, I don't think there will be any templates. We'll seed a few, and hopefully others will come along and contribute a few. But I think, even if the project gets some traction, it will be a while before we have any great number of templates. I think categorization is a great idea, but I worry about spending too much time on it if the categories are just going to be empty.
# deployable template screen
- Rating / 'liking'
- Links to templates
- Click to view / (edit if owner)
- Download
- CommentsS
I like this view. A few thoughts:
- The names "Deployable" and "Template" are maybe not the clearest things we could use. Though I imagine that using different names than in the app would be terribly confusing, and I hardly intend to suggest that we should change the names we use in-app again. I wonder if there's something slick you could do with icons here, to make it clear that a template described how to build an image, whereas a deployment was how to launch one or more images built from templates?
- For the "Download" and "Clone" buttons, I have this baseless feeling that the ordering should be flipped. I tend to expect the button on the right to be the "default" action. (Maybe something with coloring could help too?)
- I had to stop and think for a minute what "Clone" would do. I like the idea, though I don't know if it should be a "Version 1" requirement.
# template screen
- Rating
- Download
- Click to view textarea/ (edit if owner)
- Comments
- Used by ...(deployables)
Looks good! Though with the same comment about download/clone as above.
# New template screen
- Upload button
- Edit from boilerplate in textarea
I like the from file + from URL options.
I wonder about the utility of editing a boilerplate template. It seems like we'd want people to upload existing, tested templates, while a "edit this boilerplate" form would invite people to make it up on the fly.
Sidenote: This makes me realize that we probably need to *validate* these templates when they're uploaded, both for syntax and to make sure that they reference something useful.
# New deployable screen
- Upload button
- Edit from boilerplate textarea
- Select template from gallery populated list
I missed this screen, but this sounds good, except for the boilerplate comment above.
==============================
There is some potential duplication of features here for what would make a perfect conductor start-here-page. Imagine being greeted with a screen that says:
"new template (upload/edit)" and "select from templates gallery"
the "select from templates gallery" - no idea yet on how to best present this
Yes! Loving this idea. Or at least incorporating parts of this into our app.
-- Matt
Il 6/20/12 3:45 PM, Matt Wagner ha scritto:
On Tue, Jun 12, 2012 at 04:46:36PM +1000, Andy Fitzsimon wrote:
So building on this,
Here's a rough architecture of pages
Sorry for not responding sooner. I've been kind of eagerly awaiting your response, and Justin's reply made me realize that it's been sitting in my mailbox for a week. :-[
/me like Matt.
# Login screen
- oauth: google / openid, facebook, twitter etc
As a login screen, I think this is good.
The placement in this set sort of implies that you need to log in before you can do anything. I had kind of imagined that 95% of people would "just" grab a template, and only 5% of users would actually create any. So I think requiring login for normal operation would just be a barrier to entry. (I'm not sure if you're actually suggesting that they should have to log in before downloading templates and whatnot, though.)
Can you actually use GitHub as a login source? That would be neat!
It's already done the authentication system with all those things. We've the needed gems configured to manage them.
# Gallery page ( default page )
- Pagination
- Categories
I was thinking, and I did in the model, to use the *Tag* element to caracterize an *Entry* so it will be easy to search within tags
I like the graphic for single image versus multi-image deployables.
By "Categories", do you mean the Newest/Popular/Highest-Rated sort of categories you show, or do you also envision a more hierarchical layout, e.g., "Web apps", "Financial apps", "Game servers", etc.? (Those are terrible categories on my part, but you get the idea.)
My fear here is that, initially, I don't think there will be any templates. We'll seed a few, and hopefully others will come along and contribute a few. But I think, even if the project gets some traction, it will be a while before we have any great number of templates. I think categorization is a great idea, but I worry about spending too much time on it if the categories are just going to be empty.
# deployable template screen
- Rating / 'liking'
- Links to templates
- Click to view / (edit if owner)
- Download
- CommentsS
Yeah, that can be feasible as well. At the moment I added the voting system managed by mysql trigger, so for each vote we gonna have the avg rating.
I like this view. A few thoughts:
The names "Deployable" and "Template" are maybe not the clearest things we could use. Though I imagine that using different names than in the app would be terribly confusing, and I hardly intend to suggest that we should change the names we use in-app again. I wonder if there's something slick you could do with icons here, to make it clear that a template described how to build an image, whereas a deployment was how to launch one or more images built from templates?
For the "Download" and "Clone" buttons, I have this baseless feeling that the ordering should be flipped. I tend to expect the button on the right to be the "default" action. (Maybe something with coloring could help too?)
I had to stop and think for a minute what "Clone" would do. I like the idea, though I don't know if it should be a "Version 1" requirement.
# template screen
- Rating
- Download
- Click to view textarea/ (edit if owner)
- Comments
- Used by ...(deployables)
Looks good! Though with the same comment about download/clone as above.
# New template screen
- Upload button
- Edit from boilerplate in textarea
I like the from file + from URL options.
I wonder about the utility of editing a boilerplate template. It seems like we'd want people to upload existing, tested templates, while a "edit this boilerplate" form would invite people to make it up on the fly.
Sidenote: This makes me realize that we probably need to *validate* these templates when they're uploaded, both for syntax and to make sure that they reference something useful.
# New deployable screen
- Upload button
- Edit from boilerplate textarea
- Select template from gallery populated list
+1 even if the most logical way will be to do cut and paste of the template.
Currently I'm thinking to have also the opportunity to be real templates in order to put straight the URL in conductor with parameters in the url to substitute the variables for the specific template.
I missed this screen, but this sounds good, except for the boilerplate comment above.
==============================
There is some potential duplication of features here for what would make a perfect conductor start-here-page. Imagine being greeted with a screen that says:
"new template (upload/edit)" and "select from templates gallery"
the "select from templates gallery" - no idea yet on how to best present this
Yes! Loving this idea. Or at least incorporating parts of this into our app.
+10
-- Matt
----- Original Message -----
From: "Francesco Vollero" fvollero@redhat.com To: aeolus-devel@lists.fedorahosted.org Sent: Wednesday, June 20, 2012 11:41:52 AM Subject: Re: ACA Side Topic - Proposal: templates.aeolusproject.org
Il 6/20/12 3:45 PM, Matt Wagner ha scritto:
On Tue, Jun 12, 2012 at 04:46:36PM +1000, Andy Fitzsimon wrote:
So building on this,
Here's a rough architecture of pages
Sorry for not responding sooner. I've been kind of eagerly awaiting your response, and Justin's reply made me realize that it's been sitting in my mailbox for a week. :-[
/me like Matt.
# Login screen
- oauth: google / openid, facebook, twitter etc
As a login screen, I think this is good.
The placement in this set sort of implies that you need to log in before you can do anything. I had kind of imagined that 95% of people would "just" grab a template, and only 5% of users would actually create any. So I think requiring login for normal operation would just be a barrier to entry. (I'm not sure if you're actually suggesting that they should have to log in before downloading templates and whatnot, though.)
Can you actually use GitHub as a login source? That would be neat!
It's already done the authentication system with all those things. We've the needed gems configured to manage them.
# Gallery page ( default page )
- Pagination
- Categories
I was thinking, and I did in the model, to use the *Tag* element to caracterize an *Entry* so it will be easy to search within tags
Would I be able to search based on the template submitter's name or follow a particular person who submits templates I like/use a lot?
I like the graphic for single image versus multi-image deployables.
By "Categories", do you mean the Newest/Popular/Highest-Rated sort of categories you show, or do you also envision a more hierarchical layout, e.g., "Web apps", "Financial apps", "Game servers", etc.? (Those are terrible categories on my part, but you get the idea.)
My fear here is that, initially, I don't think there will be any templates. We'll seed a few, and hopefully others will come along and contribute a few. But I think, even if the project gets some traction, it will be a while before we have any great number of templates. I think categorization is a great idea, but I worry about spending too much time on it if the categories are just going to be empty.
# deployable template screen
- Rating / 'liking'
- Links to templates
- Click to view / (edit if owner)
- Download
- CommentsS
Yeah, that can be feasible as well. At the moment I added the voting system managed by mysql trigger, so for each vote we gonna have the avg rating.
I like this view. A few thoughts:
- The names "Deployable" and "Template" are maybe not the clearest things we could use. Though I imagine that using different names than in the app would be terribly confusing, and I hardly intend to suggest that we should change the names we use in-app again. I wonder if there's something slick you could do with icons here, to make it clear that a template described how to build an image, whereas a deployment was how to launch one or more images built from templates?
Perhaps a simple workflow (block) diagram on the login page (or after the login page) might help? IMHO it matters less what we call "Deployables" or "Templates" and more that a user can identify these elements in his/her workflow and use them correctly.
- For the "Download" and "Clone" buttons, I have this baseless
feeling that the ordering should be flipped. I tend to expect the button on the right to be the "default" action. (Maybe something with coloring could help too?)
- I had to stop and think for a minute what "Clone" would do.
Ditto here.
I like the idea, though I don't know if it should be a "Version 1" requirement.
# template screen
- Rating
- Download
- Click to view textarea/ (edit if owner)
- Comments
- Used by ...(deployables)
Looks good! Though with the same comment about download/clone as above.
# New template screen
- Upload button
- Edit from boilerplate in textarea
I like the from file + from URL options.
I wonder about the utility of editing a boilerplate template. It seems like we'd want people to upload existing, tested templates, while a "edit this boilerplate" form would invite people to make it up on the fly.
Sidenote: This makes me realize that we probably need to *validate* these templates when they're uploaded, both for syntax and to make sure that they reference something useful.
+1 for validation. Maybe we could do some basic syntax validation and then give a template a higher rating if we've actually managed to deploy and use the template. Some affordance to allow the submitter to validate the template on upload would be great.
# New deployable screen
- Upload button
- Edit from boilerplate textarea
- Select template from gallery populated list
+1 even if the most logical way will be to do cut and paste of the template.
Currently I'm thinking to have also the opportunity to be real templates in order to put straight the URL in conductor with parameters in the url to substitute the variables for the specific template.
I missed this screen, but this sounds good, except for the boilerplate comment above.
==============================
There is some potential duplication of features here for what would make a perfect conductor start-here-page. Imagine being greeted with a screen that says:
"new template (upload/edit)" and "select from templates gallery"
the "select from templates gallery" - no idea yet on how to best present this
Yes! Loving this idea. Or at least incorporating parts of this into our app.
+10
-- Matt
-- Francesco Vollero Software Engineer Aeolus Project
On Fri, Jun 08, 2012 at 09:24:05AM -0400, Hugh O. Brock wrote:
Yeah. We have to do this -- it's a blindingly obvious way to generate community interest and a real benefit for users.
I've asked Francesco to head up the effort of getting the thing built. We can host it on the Redmine machine for now -- if it gets bogged down with too many users, well, that goes in the category of problems we'd like to have.
We could also try to do this on OpenShift if it's easier/faster than hosting it on the Redmine machine. (I'm impartial, just thought I'd throw it out there as another option.)
Andy Fitz, can you help with the design? I'll then appoint someone to help Francesco get it coded up.
I'd love to help with the coding.
-- Matt
On Fri, Jun 08, 2012 at 10:30:26AM -0400, Matt Wagner wrote:
On Fri, Jun 08, 2012 at 09:24:05AM -0400, Hugh O. Brock wrote:
Yeah. We have to do this -- it's a blindingly obvious way to generate community interest and a real benefit for users.
I've asked Francesco to head up the effort of getting the thing built. We can host it on the Redmine machine for now -- if it gets bogged down with too many users, well, that goes in the category of problems we'd like to have.
We could also try to do this on OpenShift if it's easier/faster than hosting it on the Redmine machine. (I'm impartial, just thought I'd throw it out there as another option.)
Andy Fitz, can you help with the design? I'll then appoint someone to help Francesco get it coded up.
I'd love to help with the coding.
Awesome. As far as hosting, whatever you guys think is easier -- an OpenShift rails stack sounds like a great idea.
--H
On Fri, Jun 08, 2012 at 10:52:39AM -0400, Hugh O. Brock wrote:
On Fri, Jun 08, 2012 at 10:30:26AM -0400, Matt Wagner wrote:
On Fri, Jun 08, 2012 at 09:24:05AM -0400, Hugh O. Brock wrote:
Yeah. We have to do this -- it's a blindingly obvious way to generate community interest and a real benefit for users.
I've asked Francesco to head up the effort of getting the thing built. We can host it on the Redmine machine for now -- if it gets bogged down with too many users, well, that goes in the category of problems we'd like to have.
We could also try to do this on OpenShift if it's easier/faster than hosting it on the Redmine machine. (I'm impartial, just thought I'd throw it out there as another option.)
Andy Fitz, can you help with the design? I'll then appoint someone to help Francesco get it coded up.
I'd love to help with the coding.
Awesome. As far as hosting, whatever you guys think is easier -- an OpenShift rails stack sounds like a great idea.
FWIW Dan M has volunteered to work with Andy to come up with a basic info architecture and design (fitting since it was ~his idea). If we can get something together on that next week I would think we could get a prototype up and running pretty quickly after that.
--Hugh
On Fri, Jun 08, 2012 at 10:55:07AM -0400, Hugh O. Brock wrote:
On Fri, Jun 08, 2012 at 10:52:39AM -0400, Hugh O. Brock wrote:
On Fri, Jun 08, 2012 at 10:30:26AM -0400, Matt Wagner wrote:
On Fri, Jun 08, 2012 at 09:24:05AM -0400, Hugh O. Brock wrote:
Yeah. We have to do this -- it's a blindingly obvious way to generate community interest and a real benefit for users.
I've asked Francesco to head up the effort of getting the thing built. We can host it on the Redmine machine for now -- if it gets bogged down with too many users, well, that goes in the category of problems we'd like to have.
We could also try to do this on OpenShift if it's easier/faster than hosting it on the Redmine machine. (I'm impartial, just thought I'd throw it out there as another option.)
Andy Fitz, can you help with the design? I'll then appoint someone to help Francesco get it coded up.
I'd love to help with the coding.
Awesome. As far as hosting, whatever you guys think is easier -- an OpenShift rails stack sounds like a great idea.
FWIW Dan M has volunteered to work with Andy to come up with a basic info architecture and design (fitting since it was ~his idea). If we can get something together on that next week I would think we could get a prototype up and running pretty quickly after that.
Perfect. I'll pair up with them to see what we can get. I will also take Matt with me to help develop the code.
Cheers, Francesco
--Hugh
-- == Hugh Brock, hbrock@redhat.com == == Engineering Manager, Cloud BU == == Aeolus Project: Manage virtual infrastructure across clouds. == == http://aeolusproject.org ==
"I know that you believe you understand what you think I said, but I’m not sure you realize that what you heard is not what I meant." --Robert McCloskey
On 09/06/2012, at 2:40 AM, Francesco Vollero wrote: <snip>
FWIW Dan M has volunteered to work with Andy to come up with a basic info architecture and design (fitting since it was ~his idea). If we can get something together on that next week I would think we could get a prototype up and running pretty quickly after that.
Perfect. I'll pair up with them to see what we can get. I will also take Matt with me to help develop the code.
How's this for a concept for the front page, and the "details" page for a template? (drawn in pencil, local coffee shop :>)
http://justinclift.fedorapeople.org/templates.aeolusproject.org/first_visual...
The 2nd page of the pdf has some rough ideas that came up while sketching this out:
* We'll almost definitely need a "bundle" format defined, so 1 file can hold everything needed for a template. (deployable, image xml, metadata, etc)
Maybe all relevant xmls zipped together in a logical structure, similar to how LibreOffice does stuff for the ODF formats? Something like:
mytemplate.zip <--container file / |- images / image1.xml | / image2.xml | |- deployable.xml |- metadata.xml |- logo.png
?
* "Fork" a template
Had this idea while sketching stuff out. If you see a template on the site you like, but want to adjust it... click a "fork" button similar to GitHub. Maybe your changes and either add them to your own catalog or submit them back to the original author. (concept)
Note, the suggested idea of "apps.aeolusproject.org" might be very bad, from the point of view of Apple litigation:
http://en.wikipedia.org/wiki/Apple_Inc._litigation#Amazon_.22App_Store.22
If people feel it's worth considering, we can check with Red Hat Legal pretty easily.
Anyway, that's a start for an end stage concept (without workflow) we can work backwards from.
Thoughts anyone?
+ Justin
-- Aeolus Community Manager http://www.aeolusproject.org
On 21/08/2012, at 11:25 PM, Justin Clift wrote: <snip>
http://justinclift.fedorapeople.org/templates.aeolusproject.org/first_visual...
Next piece. "How to install a template"
http://justinclift.fedorapeople.org/templates.aeolusproject.org/how_to_insta...
+ Justin
-- Aeolus Community Manager http://www.aeolusproject.org
aeolus-devel@lists.fedorahosted.org