ACA Side Topic - Proposal: templates.aeolusproject.org

Andy Fitzsimon afitzsim at redhat.com
Tue Jun 12 06:46:36 UTC 2012


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
>>>
>>>
>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/aeolus-devel/attachments/20120612/cb1c87e1/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: heeffiif.png
Type: image/png
Size: 25345 bytes
Desc: not available
URL: <https://lists.fedorahosted.org/pipermail/aeolus-devel/attachments/20120612/cb1c87e1/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: iggbieei.png
Type: image/png
Size: 64870 bytes
Desc: not available
URL: <https://lists.fedorahosted.org/pipermail/aeolus-devel/attachments/20120612/cb1c87e1/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: daiiidgh.png
Type: image/png
Size: 121885 bytes
Desc: not available
URL: <https://lists.fedorahosted.org/pipermail/aeolus-devel/attachments/20120612/cb1c87e1/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: behgehaj.png
Type: image/png
Size: 103452 bytes
Desc: not available
URL: <https://lists.fedorahosted.org/pipermail/aeolus-devel/attachments/20120612/cb1c87e1/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: chighhfg.png
Type: image/png
Size: 31611 bytes
Desc: not available
URL: <https://lists.fedorahosted.org/pipermail/aeolus-devel/attachments/20120612/cb1c87e1/attachment-0004.png>


More information about the aeolus-devel mailing list