Re: [openstack-dev] [heat][horizon]Heat UI related requirements roadmap

2013-12-06 Thread Randall Burt
I hope I'm not re-opening worm cans here, and that's not my intent, but I just 
wanted to get a little clarification in-line below:

On Dec 6, 2013, at 3:24 PM, Tim Schnell tim.schn...@rackspace.com
 wrote:

 To resolve this thread, I have created 5 blueprints based on this mailing
 list discussion. I have attempted to distill the proposed specification
 down to what seemed generally agreed upon but if you feel strongly that I
 have incorrectly captured something let's talk about it!
 
 Here are the blueprints:
 
 1) Stack Keywords
 blueprint: https://blueprints.launchpad.net/heat/+spec/stack-keywords
 spec: https://wiki.openstack.org/wiki/Heat/UI#Stack_Keywords

As proposed, these look like template keywords and not stack keywords.

I may be mis-remembering the conversation around this, but it would seem to me 
this mixes tagging templates and tagging stacks. In my mind, these are separate 
things. For the stack part, it seems like I could just pass something like 
--keyword blah multiple times to python-heatclient and not have to edit the 
template I'm passing. This lets me organize my stacks the way I want rather 
than relying on the template author (who may not be me) to organize things for 
me. Alternatively, I'd at least like the ability to accept, replace, and/or 
augment the keywords the template author proposes.

 
 2) Parameter Grouping and Ordering
 blueprint: 
 https://blueprints.launchpad.net/heat/+spec/parameter-grouping-ordering
 spec: 
 https://wiki.openstack.org/wiki/Heat/UI#Parameter_Grouping_and_Ordering
 
 3) Parameter Help Text
 blueprint: 
 https://blueprints.launchpad.net/heat/+spec/add-help-text-to-template
 spec: https://wiki.openstack.org/wiki/Heat/UI#Help_Text
 
 4) Parameter Label
 blueprint: 
 https://blueprints.launchpad.net/heat/+spec/add-parameter-label-to-template
 spec: https://wiki.openstack.org/wiki/Heat/UI#Parameter_Label
 
 
 This last blueprint did not get as much discussion so I have added it with
 the discussion flag set. I think this will get more important in the
 future but I don't need to implement right now. I'd love to hear more
 thoughts about it.
 
 5) Get Parameters API Endpoint
 blueprint: 
 https://blueprints.launchpad.net/heat/+spec/get-parameters-from-api
 spec: 
 https://wiki.openstack.org/wiki/Heat/UI#New_API_Endpoint_for_Returning_Temp
 late_Parameters

History around validate_template aside, I wonder if this doesn't re-open the 
discussion around having an endpoint that will translate an entire template 
into the native format (HOT). I understand that the idea is that we normalize 
parameter values to relieve user interfaces from having to understand several 
formats supported by Heat, but it just seems to me that there's a more general 
use case here.

 
 Thanks,
 Tim

I know its probably nit-picky, but I would prefer these specs be individual 
wiki pages instead of lumped all together. At any rate, thanks for organizing 
all this!

 
 On 11/28/13 4:55 AM, Zane Bitter zbit...@redhat.com wrote:
 
 On 27/11/13 23:37, Fox, Kevin M wrote:
 Hmm... Yeah. when you tell heat client the url to a template file, you
 could set a flag telling the heat client it is in a git repo. It could
 then automatically look for repo information and set a stack metadata
 item pointing back to it.
 
 Or just store the URL.
 
 If you didn't care about taking a performance hit, heat client could
 always try and check to see if it was a git repo url. That may add
 several extra http requests though...
 
 Thanks,
 Kevin
 
 From: Clint Byrum [cl...@fewbar.com]
 Sent: Wednesday, November 27, 2013 1:04 PM
 To: openstack-dev
 Subject: Re: [openstack-dev] [heat][horizon]Heat UI related
 requirements   roadmap
 
 Excerpts from Fox, Kevin M's message of 2013-11-27 08:58:16 -0800:
 This use case is sort of a providence case. Where did the stack come
 from so I can find out more about it.
 
 
 This exhibits similar problems to our Copyright header problems. Relying
 on authors to maintain their authorship information in two places is
 cumbersome and thus the one that is not automated will likely fall out
 of sync fairly quickly.
 
 You could put a git commit field in the template itself but then it
 would be hard to keep updated.
 
 
 Or you could have Heat able to pull from any remote source rather than
 just allowing submission of the template directly. It would just be
 another column in the stack record. This would allow said support person
 to see where it came from by viewing the stack, which solves the use
 case.
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 ___
 OpenStack

Re: [openstack-dev] [heat][horizon]Heat UI related requirements roadmap

2013-12-06 Thread Tim Schnell

On 12/6/13 4:32 PM, Randall Burt randall.b...@rackspace.com wrote:

I hope I'm not re-opening worm cans here, and that's not my intent, but I
just wanted to get a little clarification in-line below:

On Dec 6, 2013, at 3:24 PM, Tim Schnell tim.schn...@rackspace.com
 wrote:

 To resolve this thread, I have created 5 blueprints based on this
mailing
 list discussion. I have attempted to distill the proposed specification
 down to what seemed generally agreed upon but if you feel strongly that
I
 have incorrectly captured something let's talk about it!
 
 Here are the blueprints:
 
 1) Stack Keywords
 blueprint: https://blueprints.launchpad.net/heat/+spec/stack-keywords
 spec: https://wiki.openstack.org/wiki/Heat/UI#Stack_Keywords

As proposed, these look like template keywords and not stack keywords.

I may be mis-remembering the conversation around this, but it would seem
to me this mixes tagging templates and tagging stacks. In my mind, these
are separate things. For the stack part, it seems like I could just pass
something like --keyword blah multiple times to python-heatclient and
not have to edit the template I'm passing. This lets me organize my
stacks the way I want rather than relying on the template author (who may
not be me) to organize things for me. Alternatively, I'd at least like
the ability to accept, replace, and/or augment the keywords the template
author proposes.
There was discussion about the particular implementation which didn't feel
quite resolved to me. The 2 options being, putting keywords in the
template and then parsing them out to store separately in the database and
what you suggest, passing them in along with the template.

The thought behind putting them in the template was to make it more
apparent during a stack update that the keywords may need to be updated.
As long as the final implementation is passing these keywords back via
stack-list and stack-show and allows for the user interface to query
stacks by keyword then it solves the use case.

I didn't change the initial proposal because after scoping the use case to
stack keywords I didn't notice any major negative response. Does including
the keywords within the template cause major heartburn?

 
 2) Parameter Grouping and Ordering
 blueprint: 
 https://blueprints.launchpad.net/heat/+spec/parameter-grouping-ordering
 spec: 
 https://wiki.openstack.org/wiki/Heat/UI#Parameter_Grouping_and_Ordering
 
 3) Parameter Help Text
 blueprint: 
 https://blueprints.launchpad.net/heat/+spec/add-help-text-to-template
 spec: https://wiki.openstack.org/wiki/Heat/UI#Help_Text
 
 4) Parameter Label
 blueprint: 
 
https://blueprints.launchpad.net/heat/+spec/add-parameter-label-to-templa
te
 spec: https://wiki.openstack.org/wiki/Heat/UI#Parameter_Label
 
 
 This last blueprint did not get as much discussion so I have added it
with
 the discussion flag set. I think this will get more important in the
 future but I don't need to implement right now. I'd love to hear more
 thoughts about it.
 
 5) Get Parameters API Endpoint
 blueprint: 
 https://blueprints.launchpad.net/heat/+spec/get-parameters-from-api
 spec: 
 
https://wiki.openstack.org/wiki/Heat/UI#New_API_Endpoint_for_Returning_Te
mp
 late_Parameters

History around validate_template aside, I wonder if this doesn't re-open
the discussion around having an endpoint that will translate an entire
template into the native format (HOT). I understand that the idea is that
we normalize parameter values to relieve user interfaces from having to
understand several formats supported by Heat, but it just seems to me
that there's a more general use case here.

Agreed, I can definitely see future use cases that would support an
endpoint to converge the entire template. :)

 
 Thanks,
 Tim

I know its probably nit-picky, but I would prefer these specs be
individual wiki pages instead of lumped all together. At any rate, thanks
for organizing all this!

Doh! Will do next go round.

Thanks,
Tim

 
 On 11/28/13 4:55 AM, Zane Bitter zbit...@redhat.com wrote:
 
 On 27/11/13 23:37, Fox, Kevin M wrote:
 Hmm... Yeah. when you tell heat client the url to a template file, you
 could set a flag telling the heat client it is in a git repo. It could
 then automatically look for repo information and set a stack metadata
 item pointing back to it.
 
 Or just store the URL.
 
 If you didn't care about taking a performance hit, heat client could
 always try and check to see if it was a git repo url. That may add
 several extra http requests though...
 
 Thanks,
 Kevin
 
 From: Clint Byrum [cl...@fewbar.com]
 Sent: Wednesday, November 27, 2013 1:04 PM
 To: openstack-dev
 Subject: Re: [openstack-dev] [heat][horizon]Heat UI related
 requirements   roadmap
 
 Excerpts from Fox, Kevin M's message of 2013-11-27 08:58:16 -0800:
 This use case is sort of a providence case. Where did the stack come
 from so I can find out more about it.
 
 
 This exhibits similar problems to our

Re: [openstack-dev] [heat][horizon]Heat UI related requirements roadmap

2013-11-28 Thread Zane Bitter

On 27/11/13 23:37, Fox, Kevin M wrote:

Hmm... Yeah. when you tell heat client the url to a template file, you could 
set a flag telling the heat client it is in a git repo. It could then 
automatically look for repo information and set a stack metadata item pointing 
back to it.


Or just store the URL.


If you didn't care about taking a performance hit, heat client could always try 
and check to see if it was a git repo url. That may add several extra http 
requests though...

Thanks,
Kevin

From: Clint Byrum [cl...@fewbar.com]
Sent: Wednesday, November 27, 2013 1:04 PM
To: openstack-dev
Subject: Re: [openstack-dev] [heat][horizon]Heat UI related requirements   
roadmap

Excerpts from Fox, Kevin M's message of 2013-11-27 08:58:16 -0800:

This use case is sort of a providence case. Where did the stack come from so I 
can find out more about it.



This exhibits similar problems to our Copyright header problems. Relying
on authors to maintain their authorship information in two places is
cumbersome and thus the one that is not automated will likely fall out
of sync fairly quickly.


You could put a git commit field in the template itself but then it would be 
hard to keep updated.



Or you could have Heat able to pull from any remote source rather than
just allowing submission of the template directly. It would just be
another column in the stack record. This would allow said support person
to see where it came from by viewing the stack, which solves the use case.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [heat][horizon]Heat UI related requirements roadmap

2013-11-27 Thread Thomas Spatzier
Excerpts from Tim Schnell's message on 27.11.2013 00:44:04:
 From: Tim Schnell tim.schn...@rackspace.com
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org,
 Date: 27.11.2013 00:47
 Subject: Re: [openstack-dev] [heat][horizon]Heat UI related
 requirements  roadmap



snip

 That is not the use case that I'm attempting to make, let me try again.
 For what it's worth I agree, that in this use case I want a mechanism to
 tag particular versions of templates your solution makes sense and will
 probably be necessary as the requirements for the template catalog start
 to become defined.

 What I am attempting to explain is actually much simpler than that. There
 are 2 times in a UI that I would be interested in the keywords of the
 template. When I am initially browsing the catalog to create a new stack,
 I expect the stacks to be searchable and/or organized by these keywords
 AND when I am viewing the stack-list page I should be able to sort my
 existing stacks by keywords.

 In this second case I am suggesting that the end-user, not the Template
 Catalog Moderator should have control over the keywords that are defined
 in his instantiated stack. So if he does a Stack Update, he is not
 committing a new version of the template back to a git repository, he is
 just updating the definition of the stack. If the user decides that the
 original template defined the keyword as wordpress and he wants to
 revise the keyword to tims wordpress then he can do that without the
 original template moderator knowing or caring about it.

 This could be useful to an end-user who's business is managing client
 stacks on one account maybe. So he could have tims wordpress, tims
 drupal, angus wordpress, angus drupal the way that he updates the
 keywords after the stack has been instantiated is up to him. Then he can
 sort or search his stacks on his own custom keywords.


For me this all sounds like really user specific tagging, so something that
should really be done outside the template file itself in the template
catalog service. The use case seems about a role that organizes templates
(or later stacks) by some means, which is fine, but then everything is a
decision of the person organizing the templates, and not necessarily a
decision of the template author. So it would be cleaner to keep this
tagging outside the template IMO.

 I agree that the template versioning is a separate use case.

 Tim
 
 
 Tim
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [heat][horizon]Heat UI related requirements roadmap

2013-11-27 Thread Thomas Spatzier
Excerpts from Steve Baker's message on 26.11.2013 23:29:06:

 From: Steve Baker sba...@redhat.com
 To: openstack-dev@lists.openstack.org,
 Date: 26.11.2013 23:32
 Subject: Re: [openstack-dev] [heat][horizon]Heat UI related
 requirements  roadmap

 On 11/27/2013 11:02 AM, Christopher Armstrong wrote:
 On Tue, Nov 26, 2013 at 3:24 PM, Tim Schnell tim.schn...@rackspace.com
  wrote:

snip

 Good point, I'd like to revise my previous parameter-groups example:
 parameter-groups:
 - name: db
   description: Database configuration options
   parameters: [db_name, db_username, db_password]
 - name: web_node
   description: Web server configuration
   parameters: [web_node_name, keypair]
 parameters:
   # as above, but without requiring any order or group attributes

+1 on this approach. Very clean and gives you all the information you would
need to the UI use case.
And as you say, does not have any impact on the current way parameters are
processed by Heat.


 Here, parameter-groups is a list which implies the order, and
 parameters are specified in the group as a list, so we get the order
 from that too. This means a new parameter-groups section which
 contains anything required to build a good parameters form, and no
 modifications required to the parameters section at all.

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [heat][horizon]Heat UI related requirements roadmap

2013-11-27 Thread Tim Schnell
Ok, I just re-read my example and that was a terrible example. I'll try
and create the user story first and hopefully answer Clint's and Thomas's
concerns.


If the only use case for adding keywords to the template is to help
organize the template catalog then I would agree the keywords would go
outside of heat. The second purpose for keywords is why I think they
belong in the template so I'll cover that.

Let's assume that an end-user of Heat has spun up 20 stacks and has now
requested help from a Support Operator of heat. In this case, the end-user
did not have a solid naming convention for naming his stacks, they are all
named tim1, tim2, etcŠ And also his request to the Support Operator
was really vague, like My Wordpress stack is broken.

The first thing that the Support Operator would do, would be to pull up
end-user's stacks in either Horizon or via the heat client api. In both
cases, at the moment, he would then have to either stack-show on each
stack to look at the description of the stack or ask the end-user for a
stack-id/stack-name. This currently gets the job done but a better
experience would be for stack-list to already display some keywords about
each stack so the Support Operator would have to do less digging.

In this case the end-user only has one Wordpress stack so he would have
been annoyed if the Support Operator requested more information from him.
(Or maybe he has more than one wordpress stack, but only one currently in
CREATE_FAILED state).

As a team, we have already encountered this exact situation just doing
team testing so I imagine that others would find value in a consistent way
to determine at least a general purpose of a stack, from the stack-list
page. Putting the stack-description in the stack-list table would take up
too much room from a design standpoint.

Once keywords has been added to the template then part of the blueprint
would be to return it with the stack-list information.

The previous example I attempted to explain is really more of an edge
case, so let's ignore it for now.

Thanks,
Tim

On 11/27/13 3:19 AM, Thomas Spatzier thomas.spatz...@de.ibm.com wrote:

Excerpts from Tim Schnell's message on 27.11.2013 00:44:04:
 From: Tim Schnell tim.schn...@rackspace.com
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org,
 Date: 27.11.2013 00:47
 Subject: Re: [openstack-dev] [heat][horizon]Heat UI related
 requirements  roadmap



snip

 That is not the use case that I'm attempting to make, let me try again.
 For what it's worth I agree, that in this use case I want a mechanism
to
 tag particular versions of templates your solution makes sense and will
 probably be necessary as the requirements for the template catalog start
 to become defined.

 What I am attempting to explain is actually much simpler than that.
There
 are 2 times in a UI that I would be interested in the keywords of the
 template. When I am initially browsing the catalog to create a new
stack,
 I expect the stacks to be searchable and/or organized by these keywords
 AND when I am viewing the stack-list page I should be able to sort my
 existing stacks by keywords.

 In this second case I am suggesting that the end-user, not the Template
 Catalog Moderator should have control over the keywords that are defined
 in his instantiated stack. So if he does a Stack Update, he is not
 committing a new version of the template back to a git repository, he is
 just updating the definition of the stack. If the user decides that the
 original template defined the keyword as wordpress and he wants to
 revise the keyword to tims wordpress then he can do that without the
 original template moderator knowing or caring about it.

 This could be useful to an end-user who's business is managing client
 stacks on one account maybe. So he could have tims wordpress, tims
 drupal, angus wordpress, angus drupal the way that he updates the
 keywords after the stack has been instantiated is up to him. Then he can
 sort or search his stacks on his own custom keywords.


For me this all sounds like really user specific tagging, so something
that
should really be done outside the template file itself in the template
catalog service. The use case seems about a role that organizes templates
(or later stacks) by some means, which is fine, but then everything is a
decision of the person organizing the templates, and not necessarily a
decision of the template author. So it would be cleaner to keep this
tagging outside the template IMO.

 I agree that the template versioning is a separate use case.

 Tim
 
 
 Tim
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat][horizon]Heat UI related requirements roadmap

2013-11-27 Thread Zane Bitter

On 26/11/13 22:24, Tim Schnell wrote:

Use Case #1
I see valid value in being able to group templates based on a type or


+1, me too.


keyword. This would allow any client, Horizon or a Template Catalog
service, to better organize and handle display options for an end-user.


I believe these are separate use cases and deserve to be elaborated as 
such. If one feature can help with both that's great, but we're putting 
the cart before the horse if we jump in and implement the feature 
without knowing why.


Let's consider first a catalog of operator-provided templates as 
proposed (IIUC) by Keith. It seems clear to me in that instance the 
keywords are a property of the template's position in the catalog, and 
not of the template itself.


Horizon is a slightly different story. Do we even allow people to upload 
a bunch of templates and store them in Horizon? If not then there 
doesn't seem much point in this feature for current Horizon users. (And 
if we do, which would surprise me greatly, then the proposed 
implementation doesn't seem that practical - would we want to retrieve 
and parse every template to get the keyword?)


In the longer term, there seems to be a lot of demand for some sort of 
template catalog service, like Glance for templates. (I disagree with 
Clint that it should actually _be_ Glance the project as we know it, for 
the reasons Steve B mentioned earlier, but the concept is right.) And 
this brings us back to a very similar situation to the operator-provided 
template catalog (indeed, that use case would likely be subsumed by this 
one).



I believe that Ladislav initially proposed a solution that will work here.
So I will second a proposal that we add a new top-level field to the HOT
specification called keywords that contains this template type.

keywords: wordpress, mysql, etcŠ


+1. If we decide that the template is the proper place for these tags 
then this is the perfect way to do it IMO (assuming that it's actually a 
list, not a comma-separated string). It's a standard format that we can 
document and any tool can recognise, the name keywords describes 
exactly what it does and there's no confusion with tags in Nova and EC2.



Use Case #2
The template author should also be able to explicitly define a help string
that is distinct and separate from the description of an individual


This is not a use case, it's a specification. There seems to be a lot of 
confusion about the difference, so let me sum it up:


Why - Use Case
What - Specification
How - Design Document (i.e. Code)

I know this all sounds very top-down, and believe me that's not my 
philosophy. But design is essentially a global optimisation problem - we 
need to see the whole picture to properly evaluate any given design (or, 
indeed, to find an alternate design), and you're only giving us one 
small piece near the very bottom.


A use case is something that a user of Heat needs to do.

An example of a use case would be: The user needs to see two types of 
information in Horizon that are styled differently/shown at different 
times/other (please specify) so that they can __.


I'm confident that a valid use case _does_ actually exist here, but you 
haven't described it yet.



parameter. An example where this use case originated was with Nova
Keypairs. The description of a keypair parameter might be something like,
This is the name of a nova key pair that will be used to ssh to the
compute instance. A help string for this same parameter would be, To
learn more about nova keypairs click on this help article.


It's not at all clear to me that these are different pieces of 
information. They both describe the parameter and they're both there to 
help the user. It would be easier to figure out what the right thing 
would be if you gave an example of what you had in mind for how Horizon 
should display these. Even without that, though, it seems to me that the 
help is just adding more detail to the description.


One idea I suggested in the review comments is to just interpret the 
first paragraph as the description and any subsequent paragraphs as the 
help. There is ample precedent for that kind of interpretation in things 
like Python docstrings and Git commit messages.



I propose adding an additional field to the parameter definition:

Parameters:
parameter name:
description: This is the name of a nova key pair that 
will be used to
ssh to the compute instance.
help: To learn more about nova key pairs click on this 
a
href=/some/url/help article/a.


(Side note: you're seriously going to let users stick HTML in the 
template and then have the dashboard display it?  Yikes.)



Use Case #3
Grouping parameters would help the client make smarter decisions about how
to display the parameters for input to the end-user. This is so that all
parameters related to some database resource can be intelligently 

Re: [openstack-dev] [heat][horizon]Heat UI related requirements roadmap

2013-11-27 Thread Tim Schnell

On 11/27/13 10:39 AM, Zane Bitter zbit...@redhat.com wrote:

On 26/11/13 23:44, Tim Schnell wrote:
 A template-validate call would need to return all the group and
ordering
 information, but otherwise heat can ignore this extra data.
 I agree with all of your modifications, although bringing up the
 template-validate call reminded me that the implementation of this use
 case should also imply a new REST endpoint specifically for returning
 parameters. It seems like the current implementation in Horizon is a bit
 hack-y by calling template-validate instead of something like
 get-parameters.

That's inherited from how the cfn-compatible API does it, but it doesn't
seem hacky to me. And it matches exactly how the UI works - you upload a
template, it validates it and gets back the list of parameters.

This raises a good point though - it ought to be Heat that determines
the order of the parameters and returns them in a list (like heat-cfn
does - though the list is currently randomly ordered). Clients need to
treat the template as a black box, since the format changes over time.

I would be fine with Heat returning the parameters already ordered
(dependent on the order recognizing parameter grouping). I don't have a
strong opinion about the naming convention of the REST API call that I
have to make to get the parameters but I would also like to start
discussing including the current parameter values in whatever api call
this ends up being. For a Stack Update, I would like to populate the
parameters with previously entered values, although this has further
implications for values that are encrypted, like passwords.

Horizon, currently does not implement a Stack Update and this has been one
of the major sticking points for me trying to figure out how to provide an
interface for it.

I would imagine that adding the parameter values to the template validate
response would make it more obvious that it may warrant a separate
endpoint. Then template_validate can(should?) simply return a boolean
value.

Tim

cheers,
Zane.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [heat][horizon]Heat UI related requirements roadmap

2013-11-27 Thread Fox, Kevin M
This use case is sort of a providence case. Where did the stack come from so I 
can find out more about it.

You could put a git commit field in the template itself but then it would be 
hard to keep updated.

How about the following:

Extend heat to support setting a scmcommit metadata item on stack create. 
Heat will ignore this but make it available for retrieval.

I'm guessing any catalog will have some sort of scm managing the templates. 
When you go and submit the stack, you can set the metadata and know exactly 
when and where and all the history of the stack by just referring to the git 
commit string.

This should tell you far more then a set of strings a user could set for their 
own use, confusing others.

Thanks,
Kevin


From: Tim Schnell [tim.schn...@rackspace.com]
Sent: Wednesday, November 27, 2013 7:24 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [heat][horizon]Heat UI related requirements  
roadmap

Ok, I just re-read my example and that was a terrible example. I'll try
and create the user story first and hopefully answer Clint's and Thomas's
concerns.


If the only use case for adding keywords to the template is to help
organize the template catalog then I would agree the keywords would go
outside of heat. The second purpose for keywords is why I think they
belong in the template so I'll cover that.

Let's assume that an end-user of Heat has spun up 20 stacks and has now
requested help from a Support Operator of heat. In this case, the end-user
did not have a solid naming convention for naming his stacks, they are all
named tim1, tim2, etcŠ And also his request to the Support Operator
was really vague, like My Wordpress stack is broken.

The first thing that the Support Operator would do, would be to pull up
end-user's stacks in either Horizon or via the heat client api. In both
cases, at the moment, he would then have to either stack-show on each
stack to look at the description of the stack or ask the end-user for a
stack-id/stack-name. This currently gets the job done but a better
experience would be for stack-list to already display some keywords about
each stack so the Support Operator would have to do less digging.

In this case the end-user only has one Wordpress stack so he would have
been annoyed if the Support Operator requested more information from him.
(Or maybe he has more than one wordpress stack, but only one currently in
CREATE_FAILED state).

As a team, we have already encountered this exact situation just doing
team testing so I imagine that others would find value in a consistent way
to determine at least a general purpose of a stack, from the stack-list
page. Putting the stack-description in the stack-list table would take up
too much room from a design standpoint.

Once keywords has been added to the template then part of the blueprint
would be to return it with the stack-list information.

The previous example I attempted to explain is really more of an edge
case, so let's ignore it for now.

Thanks,
Tim

On 11/27/13 3:19 AM, Thomas Spatzier thomas.spatz...@de.ibm.com wrote:

Excerpts from Tim Schnell's message on 27.11.2013 00:44:04:
 From: Tim Schnell tim.schn...@rackspace.com
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org,
 Date: 27.11.2013 00:47
 Subject: Re: [openstack-dev] [heat][horizon]Heat UI related
 requirements  roadmap



snip

 That is not the use case that I'm attempting to make, let me try again.
 For what it's worth I agree, that in this use case I want a mechanism
to
 tag particular versions of templates your solution makes sense and will
 probably be necessary as the requirements for the template catalog start
 to become defined.

 What I am attempting to explain is actually much simpler than that.
There
 are 2 times in a UI that I would be interested in the keywords of the
 template. When I am initially browsing the catalog to create a new
stack,
 I expect the stacks to be searchable and/or organized by these keywords
 AND when I am viewing the stack-list page I should be able to sort my
 existing stacks by keywords.

 In this second case I am suggesting that the end-user, not the Template
 Catalog Moderator should have control over the keywords that are defined
 in his instantiated stack. So if he does a Stack Update, he is not
 committing a new version of the template back to a git repository, he is
 just updating the definition of the stack. If the user decides that the
 original template defined the keyword as wordpress and he wants to
 revise the keyword to tims wordpress then he can do that without the
 original template moderator knowing or caring about it.

 This could be useful to an end-user who's business is managing client
 stacks on one account maybe. So he could have tims wordpress, tims
 drupal, angus wordpress, angus drupal the way that he updates the
 keywords after the stack has been

Re: [openstack-dev] [heat][horizon]Heat UI related requirements roadmap

2013-11-27 Thread Edmund Troche
You bring up a good point Thomas. I think some of the discussions are
mixing template and stack perspectives, they are not the same thing, stack
== instance of a template. There likely is room for tagging stacks, all
under the control of the user and meant for user consumption, vs the long
going discussion on template-level metadata. This may be yet another use
case ;-)

  
   Edmund Troche Senior Software Engineer 
  
 IBM Software Group | 
 11501 Burnet Rd. |   
 Austin, TX 78758 
  
 ( +1.512.286.8977 ) T/L  
 363.8977 *   
 edmund.tro...@us.ibm.com 
 7 +1.512.286.8977
  






From:   Thomas Spatzier thomas.spatz...@de.ibm.com
To: OpenStack Development Mailing List \(not for usage questions
\) openstack-dev@lists.openstack.org,
Date:   11/27/2013 11:00 AM
Subject:Re: [openstack-dev] [heat][horizon]Heat UI related requirements
   roadmap



Thanks, that clarified the use case a bit. Bot looking at the use case now,
isn't this stack tagging instead of template tagging?
I.e. assume that for each stack a user creates, he/she can assign one or
more tags so you can do better queries to find stacks later?

Regards,
Thomas

Tim Schnell tim.schn...@rackspace.com wrote on 27.11.2013 16:24:18:
 From: Tim Schnell tim.schn...@rackspace.com
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org,
 Date: 27.11.2013 16:28
 Subject: Re: [openstack-dev] [heat][horizon]Heat UI related
 requirements  roadmap

 Ok, I just re-read my example and that was a terrible example. I'll try
 and create the user story first and hopefully answer Clint's and Thomas's
 concerns.


 If the only use case for adding keywords to the template is to help
 organize the template catalog then I would agree the keywords would go
 outside of heat. The second purpose for keywords is why I think they
 belong in the template so I'll cover that.

 Let's assume that an end-user of Heat has spun up 20 stacks and has now
 requested help from a Support Operator of heat. In this case, the
end-user
 did not have a solid naming convention for naming his stacks, they are
all
 named tim1, tim2, etcŠ And also his request to the Support Operator
 was really vague, like My Wordpress stack is broken.

 The first thing that the Support Operator would do, would be to pull up
 end-user's stacks in either Horizon or via the heat client api. In both
 cases, at the moment, he would then have to either stack-show on each
 stack to look at the description of the stack or ask the end-user for a
 stack-id/stack-name. This currently gets the job done but a better
 experience would be for stack-list to already display some keywords about
 each stack so the Support Operator would have to do less digging.

 In this case the end-user only has one Wordpress stack so he would have
 been annoyed if the Support Operator requested more information from him.
 (Or maybe he has more than one wordpress stack, but only one currently in
 CREATE_FAILED state).

 As a team, we have already encountered this exact situation just doing
 team testing so I imagine that others would find value in a consistent
way
 to determine at least a general purpose of a stack, from the stack-list
 page. Putting the stack-description in the stack-list table would take up
 too much room from a design standpoint.

 Once keywords has been added to the template then part of the blueprint
 would be to return it with the stack-list information.

 The previous example I attempted to explain is really more of an edge
 case, so let's ignore it for now.

 Thanks,
 Tim

 On 11/27/13 3:19 AM, Thomas Spatzier thomas.spatz...@de.ibm.com
wrote:

 Excerpts from Tim Schnell's message on 27.11.2013 00:44:04:
  From: Tim Schnell tim.schn...@rackspace.com
  To: OpenStack Development Mailing List (not for usage questions)
  openstack-dev@lists.openstack.org,
  Date: 27.11.2013 00:47
  Subject: Re: [openstack-dev] [heat][horizon]Heat UI related
  requirements  roadmap
 
 
 
 snip
 
  That is not the use case that I'm attempting to make, let me try
again.
  For what it's worth I agree, that in this use case I want a mechanism
 to
  tag particular versions of templates your solution makes sense and
will
  probably be necessary as the requirements for the template catalog
start
  to become defined.
 
  What I am

Re: [openstack-dev] [heat][horizon]Heat UI related requirements roadmap

2013-11-27 Thread Clint Byrum
Excerpts from Zane Bitter's message of 2013-11-27 08:09:33 -0800:
 In the longer term, there seems to be a lot of demand for some sort of 
 template catalog service, like Glance for templates. (I disagree with 
 Clint that it should actually _be_ Glance the project as we know it, for 
 the reasons Steve B mentioned earlier, but the concept is right.) And 
 this brings us back to a very similar situation to the operator-provided 
 template catalog (indeed, that use case would likely be subsumed by this 
 one).
 

Could you provide a stronger link to Steve B's comments, I think I
missed them. Thanks!

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [heat][horizon]Heat UI related requirements roadmap

2013-11-27 Thread Tim Schnell

On 11/27/13 10:09 AM, Zane Bitter zbit...@redhat.com wrote:

On 26/11/13 22:24, Tim Schnell wrote:
 Use Case #1
 I see valid value in being able to group templates based on a type or

+1, me too.

 keyword. This would allow any client, Horizon or a Template Catalog
 service, to better organize and handle display options for an end-user.

I believe these are separate use cases and deserve to be elaborated as
such. If one feature can help with both that's great, but we're putting
the cart before the horse if we jump in and implement the feature
without knowing why.

Let's consider first a catalog of operator-provided templates as
proposed (IIUC) by Keith. It seems clear to me in that instance the
keywords are a property of the template's position in the catalog, and
not of the template itself.

Horizon is a slightly different story. Do we even allow people to upload
a bunch of templates and store them in Horizon? If not then there
doesn't seem much point in this feature for current Horizon users. (And
if we do, which would surprise me greatly, then the proposed
implementation doesn't seem that practical - would we want to retrieve
and parse every template to get the keyword?)

Correct, at the moment, Horizon has no concept of a template catalog of
any kind.

Here is my use case for including this in the template for Horizon:
(I'm going to start moving these to the wiki that Steve Baker setup)

Let's assume that an end-user of Heat has spun up 20 stacks and has now
requested help from a Support Operator of heat. In this case, the end-user
did not have a solid naming convention for naming his stacks, they are all
named tim1, tim2, etcŠ And also his request to the Support Operator
was really vague, like My Wordpress stack is broken.

The first thing that the Support Operator would do, would be to pull up
end-user's stacks in either Horizon or via the heat client cli. In both
cases, at the moment, he would then have to either stack-show on each
stack to look at the description of the stack or ask the end-user for a
stack-id/stack-name. This currently gets the job done but a better
experience would be for stack-list to already display some keywords about
each stack so the Support Operator would have to do less digging.

In this case the end-user only has one Wordpress stack so he would have
been annoyed if the Support Operator requested more information from him.
(Or maybe he has more than one wordpress stack, but only one currently in
CREATE_FAILED state).

As a team, we have already encountered this exact situation just doing
team testing so I imagine that others would find value in a consistent way
to determine at least a general purpose of a stack, from the stack-list
page. Putting the stack-description in the stack-list table would take up
too much room from a design standpoint.

Once keywords has been added to the template then part of the blueprint
would be to return it with the stack-list information.




In the longer term, there seems to be a lot of demand for some sort of
template catalog service, like Glance for templates. (I disagree with
Clint that it should actually _be_ Glance the project as we know it, for
the reasons Steve B mentioned earlier, but the concept is right.) And
this brings us back to a very similar situation to the operator-provided
template catalog (indeed, that use case would likely be subsumed by this
one).

 I believe that Ladislav initially proposed a solution that will work
here.
 So I will second a proposal that we add a new top-level field to the HOT
 specification called keywords that contains this template type.

  keywords: wordpress, mysql, etcŠ

+1. If we decide that the template is the proper place for these tags
then this is the perfect way to do it IMO (assuming that it's actually a
list, not a comma-separated string). It's a standard format that we can
document and any tool can recognise, the name keywords describes
exactly what it does and there's no confusion with tags in Nova and EC2.

 Use Case #2
 The template author should also be able to explicitly define a help
string
 that is distinct and separate from the description of an individual

This is not a use case, it's a specification. There seems to be a lot of
confusion about the difference, so let me sum it up:

Why - Use Case
What - Specification
How - Design Document (i.e. Code)

I know this all sounds very top-down, and believe me that's not my
philosophy. But design is essentially a global optimisation problem - we
need to see the whole picture to properly evaluate any given design (or,
indeed, to find an alternate design), and you're only giving us one
small piece near the very bottom.

A use case is something that a user of Heat needs to do.

An example of a use case would be: The user needs to see two types of
information in Horizon that are styled differently/shown at different
times/other (please specify) so that they can __.

I'm confident that a valid use case _does_ 

Re: [openstack-dev] [heat][horizon]Heat UI related requirements roadmap

2013-11-27 Thread Tim Schnell
Yes, I guess you could phrase it as stack tagging, focusing on the
template was my attempt to solve 2 use cases with one solution but I'M
open to alternatives. Are you suggesting that we build the ability to add
tags to stacks that exist outside of the template? I guess add them
directly to Heat's database?

Tim Schnell
Software Developer
Rackspace





On 11/27/13 10:53 AM, Thomas Spatzier thomas.spatz...@de.ibm.com wrote:

Thanks, that clarified the use case a bit. Bot looking at the use case
now,
isn't this stack tagging instead of template tagging?
I.e. assume that for each stack a user creates, he/she can assign one or
more tags so you can do better queries to find stacks later?

Regards,
Thomas

Tim Schnell tim.schn...@rackspace.com wrote on 27.11.2013 16:24:18:
 From: Tim Schnell tim.schn...@rackspace.com
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org,
 Date: 27.11.2013 16:28
 Subject: Re: [openstack-dev] [heat][horizon]Heat UI related
 requirements  roadmap

 Ok, I just re-read my example and that was a terrible example. I'll try
 and create the user story first and hopefully answer Clint's and
Thomas's
 concerns.


 If the only use case for adding keywords to the template is to help
 organize the template catalog then I would agree the keywords would go
 outside of heat. The second purpose for keywords is why I think they
 belong in the template so I'll cover that.

 Let's assume that an end-user of Heat has spun up 20 stacks and has now
 requested help from a Support Operator of heat. In this case, the
end-user
 did not have a solid naming convention for naming his stacks, they are
all
 named tim1, tim2, etcŠ And also his request to the Support Operator
 was really vague, like My Wordpress stack is broken.

 The first thing that the Support Operator would do, would be to pull up
 end-user's stacks in either Horizon or via the heat client api. In both
 cases, at the moment, he would then have to either stack-show on each
 stack to look at the description of the stack or ask the end-user for a
 stack-id/stack-name. This currently gets the job done but a better
 experience would be for stack-list to already display some keywords
about
 each stack so the Support Operator would have to do less digging.

 In this case the end-user only has one Wordpress stack so he would have
 been annoyed if the Support Operator requested more information from
him.
 (Or maybe he has more than one wordpress stack, but only one currently
in
 CREATE_FAILED state).

 As a team, we have already encountered this exact situation just doing
 team testing so I imagine that others would find value in a consistent
way
 to determine at least a general purpose of a stack, from the stack-list
 page. Putting the stack-description in the stack-list table would take
up
 too much room from a design standpoint.

 Once keywords has been added to the template then part of the blueprint
 would be to return it with the stack-list information.

 The previous example I attempted to explain is really more of an edge
 case, so let's ignore it for now.

 Thanks,
 Tim

 On 11/27/13 3:19 AM, Thomas Spatzier thomas.spatz...@de.ibm.com
wrote:

 Excerpts from Tim Schnell's message on 27.11.2013 00:44:04:
  From: Tim Schnell tim.schn...@rackspace.com
  To: OpenStack Development Mailing List (not for usage questions)
  openstack-dev@lists.openstack.org,
  Date: 27.11.2013 00:47
  Subject: Re: [openstack-dev] [heat][horizon]Heat UI related
  requirements  roadmap
 
 
 
 snip
 
  That is not the use case that I'm attempting to make, let me try
again.
  For what it's worth I agree, that in this use case I want a
mechanism
 to
  tag particular versions of templates your solution makes sense and
will
  probably be necessary as the requirements for the template catalog
start
  to become defined.
 
  What I am attempting to explain is actually much simpler than that.
 There
  are 2 times in a UI that I would be interested in the keywords of the
  template. When I am initially browsing the catalog to create a new
 stack,
  I expect the stacks to be searchable and/or organized by these
keywords
  AND when I am viewing the stack-list page I should be able to sort my
  existing stacks by keywords.
 
  In this second case I am suggesting that the end-user, not the
Template
  Catalog Moderator should have control over the keywords that are
defined
  in his instantiated stack. So if he does a Stack Update, he is not
  committing a new version of the template back to a git repository, he
is
  just updating the definition of the stack. If the user decides that
the
  original template defined the keyword as wordpress and he wants to
  revise the keyword to tims wordpress then he can do that without
the
  original template moderator knowing or caring about it.
 
  This could be useful to an end-user who's business is managing client
  stacks on one account maybe. So he could have tims wordpress, tims
  drupal, angus

Re: [openstack-dev] [heat][horizon]Heat UI related requirements roadmap

2013-11-27 Thread Tim Schnell
On 11/27/13 10:58 AM, Fox, Kevin M kevin@pnnl.gov wrote:


This use case is sort of a providence case. Where did the stack come from
so I can find out more about it.

You could put a git commit field in the template itself but then it would
be hard to keep updated.

How about the following:

Extend heat to support setting a scmcommit metadata item on stack
create. Heat will ignore this but make it available for retrieval.

I'm guessing any catalog will have some sort of scm managing the
templates. When you go and submit the stack, you can set the metadata and
know exactly when and where and all the history of the stack by just
referring to the git commit string.

This should tell you far more then a set of strings a user could set for
their own use, confusing others.

Hi Kevin,

Yeah I think tying the keywords use case to the template catalog is what
is causing confusion. I agree that the above solution is a good way to
solve this problem for the template catalog. It would definitely be more
specific about what exactly the template represents. But if we remove the
template catalog from the equation and focus on the experience of
providing searchable keywords to the stack either in the template or in
the database. This would solve the use case I'm attempting to describe.

In my use case I'm referring to stacks that are being created with a user
generated template. Something that isn't necessarily a part of any
catalog, in Horizon you can provide a template in a direct input text area
or via file upload.

Tim

Thanks,
Kevin


From: Tim Schnell [tim.schn...@rackspace.com]
Sent: Wednesday, November 27, 2013 7:24 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [heat][horizon]Heat UI related requirements
 roadmap

Ok, I just re-read my example and that was a terrible example. I'll try
and create the user story first and hopefully answer Clint's and Thomas's
concerns.


If the only use case for adding keywords to the template is to help
organize the template catalog then I would agree the keywords would go
outside of heat. The second purpose for keywords is why I think they
belong in the template so I'll cover that.

Let's assume that an end-user of Heat has spun up 20 stacks and has now
requested help from a Support Operator of heat. In this case, the end-user
did not have a solid naming convention for naming his stacks, they are all
named tim1, tim2, etcŠ And also his request to the Support Operator
was really vague, like My Wordpress stack is broken.

The first thing that the Support Operator would do, would be to pull up
end-user's stacks in either Horizon or via the heat client api. In both
cases, at the moment, he would then have to either stack-show on each
stack to look at the description of the stack or ask the end-user for a
stack-id/stack-name. This currently gets the job done but a better
experience would be for stack-list to already display some keywords about
each stack so the Support Operator would have to do less digging.

In this case the end-user only has one Wordpress stack so he would have
been annoyed if the Support Operator requested more information from him.
(Or maybe he has more than one wordpress stack, but only one currently in
CREATE_FAILED state).

As a team, we have already encountered this exact situation just doing
team testing so I imagine that others would find value in a consistent way
to determine at least a general purpose of a stack, from the stack-list
page. Putting the stack-description in the stack-list table would take up
too much room from a design standpoint.

Once keywords has been added to the template then part of the blueprint
would be to return it with the stack-list information.

The previous example I attempted to explain is really more of an edge
case, so let's ignore it for now.

Thanks,
Tim

On 11/27/13 3:19 AM, Thomas Spatzier thomas.spatz...@de.ibm.com wrote:

Excerpts from Tim Schnell's message on 27.11.2013 00:44:04:
 From: Tim Schnell tim.schn...@rackspace.com
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org,
 Date: 27.11.2013 00:47
 Subject: Re: [openstack-dev] [heat][horizon]Heat UI related
 requirements  roadmap



snip

 That is not the use case that I'm attempting to make, let me try again.
 For what it's worth I agree, that in this use case I want a mechanism
to
 tag particular versions of templates your solution makes sense and
will
 probably be necessary as the requirements for the template catalog
start
 to become defined.

 What I am attempting to explain is actually much simpler than that.
There
 are 2 times in a UI that I would be interested in the keywords of the
 template. When I am initially browsing the catalog to create a new
stack,
 I expect the stacks to be searchable and/or organized by these keywords
 AND when I am viewing the stack-list page I should be able to sort my
 existing stacks

Re: [openstack-dev] [heat][horizon]Heat UI related requirements roadmap

2013-11-27 Thread Tim Schnell

From: Edmund Troche edmund.tro...@us.ibm.commailto:edmund.tro...@us.ibm.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Wednesday, November 27, 2013 11:08 AM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [heat][horizon]Heat UI related requirements  
roadmap


You bring up a good point Thomas. I think some of the discussions are mixing 
template and stack perspectives, they are not the same thing, stack == instance 
of a template. There likely is room for tagging stacks, all under the control 
of the user and meant for user consumption, vs the long going discussion on 
template-level metadata. This may be yet another use case ;-)


+1 yes, thanks Edmund for clarifying we are definitely talking about separate 
use cases now.

  Edmund Troche
Senior Software Engineer

IBMhttp://www.ibm.com/ Software Group | 11501 Burnet Rd. | Austin, TX 78758
* +1.512.286.8977 * T/L 363.8977 * 
edmund.tro...@us.ibm.commailto:edmund.tro...@us.ibm.com * +1.512.286.8977


[Inactive hide details for Thomas Spatzier ---11/27/2013 11:00:58 AM---Thanks, 
that clarified the use case a bit. Bot looking at]Thomas Spatzier ---11/27/2013 
11:00:58 AM---Thanks, that clarified the use case a bit. Bot looking at the use 
case now, isn't this stack tagging

From: Thomas Spatzier 
thomas.spatz...@de.ibm.commailto:thomas.spatz...@de.ibm.com
To: OpenStack Development Mailing List \(not for usage questions\) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org,
Date: 11/27/2013 11:00 AM
Subject: Re: [openstack-dev] [heat][horizon]Heat UI related requirements  
roadmap





Thanks, that clarified the use case a bit. Bot looking at the use case now,
isn't this stack tagging instead of template tagging?
I.e. assume that for each stack a user creates, he/she can assign one or
more tags so you can do better queries to find stacks later?

Regards,
Thomas

Tim Schnell tim.schn...@rackspace.commailto:tim.schn...@rackspace.com wrote 
on 27.11.2013 16:24:18:
 From: Tim Schnell 
 tim.schn...@rackspace.commailto:tim.schn...@rackspace.com
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org,
 Date: 27.11.2013 16:28
 Subject: Re: [openstack-dev] [heat][horizon]Heat UI related
 requirements  roadmap

 Ok, I just re-read my example and that was a terrible example. I'll try
 and create the user story first and hopefully answer Clint's and Thomas's
 concerns.


 If the only use case for adding keywords to the template is to help
 organize the template catalog then I would agree the keywords would go
 outside of heat. The second purpose for keywords is why I think they
 belong in the template so I'll cover that.

 Let's assume that an end-user of Heat has spun up 20 stacks and has now
 requested help from a Support Operator of heat. In this case, the
end-user
 did not have a solid naming convention for naming his stacks, they are
all
 named tim1, tim2, etcŠ And also his request to the Support Operator
 was really vague, like My Wordpress stack is broken.

 The first thing that the Support Operator would do, would be to pull up
 end-user's stacks in either Horizon or via the heat client api. In both
 cases, at the moment, he would then have to either stack-show on each
 stack to look at the description of the stack or ask the end-user for a
 stack-id/stack-name. This currently gets the job done but a better
 experience would be for stack-list to already display some keywords about
 each stack so the Support Operator would have to do less digging.

 In this case the end-user only has one Wordpress stack so he would have
 been annoyed if the Support Operator requested more information from him.
 (Or maybe he has more than one wordpress stack, but only one currently in
 CREATE_FAILED state).

 As a team, we have already encountered this exact situation just doing
 team testing so I imagine that others would find value in a consistent
way
 to determine at least a general purpose of a stack, from the stack-list
 page. Putting the stack-description in the stack-list table would take up
 too much room from a design standpoint.

 Once keywords has been added to the template then part of the blueprint
 would be to return it with the stack-list information.

 The previous example I attempted to explain is really more of an edge
 case, so let's ignore it for now.

 Thanks,
 Tim

 On 11/27/13 3:19 AM, Thomas Spatzier 
 thomas.spatz...@de.ibm.commailto:thomas.spatz...@de.ibm.com
wrote:

 Excerpts from Tim Schnell's message on 27.11.2013 00:44:04:
  From: Tim Schnell 
  tim.schn...@rackspace.commailto:tim.schn...@rackspace.com
  To: OpenStack Development Mailing List (not for usage questions)
  openstack-dev

Re: [openstack-dev] [heat][horizon]Heat UI related requirements roadmap

2013-11-27 Thread Jason Dunsmore
On Wed, Nov 27 2013, Zane Bitter wrote:


  Parameters:
  db_name:
  group: db
  order: 0
  db_username:
  group: db
  order: 1
  db_password:
  group: db
  order: 2
  web_node_name:
  group: web_node
  order: 0
  keypair:
  group: web_node
  order: 1

 -2 this is horrible.

 Imagine how much work this is for the poor author! At least they don't
 have to maintain parallel hierarchies of matching key names like in
 the original proposal, but they still have to manually maintain
 multiple lists of orderings. What if you wanted to add another
 parameter at the beginning? Maybe we should encourage authors to
 number parameters with multiples of 10. Like BASIC programmers in the
 80s.

 And of course if you don't specify the order explicitly then you get
 random order again. Sigh.

 There's only one way that this is even remotely maintainable for a
 template author, and that's if they group and order stuff manually
 anyway (like you have in your example - people will do this
 automatically by themselves even if the syntax doesn't require them
 to). Since they have to do this, just display the parameters in the UI
 in the same order that they are defined in the file. This does the
 Right Thing even if the author doesn't know about it, unlike the
 explicit order thing which completely breaks down if the order is not
 explicitly stated. You probably won't even have to document it because
 literally 100% of people will either (a) not care, or (b) expect it to
 work that way anyway. In fact, you will almost certainly get bug
 reports if you don't display them in the same order as written.

+1 for implicit ordering.  I think this will be intuitive for users.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [heat][horizon]Heat UI related requirements roadmap

2013-11-27 Thread Zane Bitter

On 27/11/13 18:12, Clint Byrum wrote:

Excerpts from Zane Bitter's message of 2013-11-27 08:09:33 -0800:

In the longer term, there seems to be a lot of demand for some sort of
template catalog service, like Glance for templates. (I disagree with
Clint that it should actually _be_ Glance the project as we know it, for
the reasons Steve B mentioned earlier, but the concept is right.) And
this brings us back to a very similar situation to the operator-provided
template catalog (indeed, that use case would likely be subsumed by this
one).



Could you provide a stronger link to Steve B's comments, I think I
missed them. Thanks!


Hrm, glance is for large binary data and has a metadata model only for 
OS images - the overlap with the needs of a template catalog don't seem 
very obvious to me.


It was longer and more detailed in my recollection of it :D Sorry!

- ZB

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [heat][horizon]Heat UI related requirements roadmap

2013-11-27 Thread Jay Pipes

On 11/27/2013 01:28 AM, Clint Byrum wrote:

I propose adding an additional field to the parameter definition:

 Parameters:
 parameter name:
 description: This is the name of a nova key pair that will be used 
to
ssh to the compute instance.
 help: To learn more about nova key pairs click on this a
href=/some/url/help article/a.


+1. A help string per parameter is a fantastic idea. Sounds like a nice
analog to doc-strings.


Agreed. The above is a nice, straightforward addition.

snip


+1 for grouping. Your use case is perfectly specified above. Love it.

However, your format feels very forced. Integers for ordering? We have
lists for that.

How about this:

parameters:
   db:
 type: group
 parameters:
   - db_name
   - db_username
   - db_password
   web_node:
 type: group
 parameters:
   - web_node_name
   - keypair
   db_name:
 type: string
   ...

This way we are just providing the groupings outside of the parameters
themselves. Using a list means the order is as it appears here.


Actually, even simpler than that...

parameters:
  db:
   - db_name:
 description: blah
 help: blah
   - db_username:
 description: blah
 help: blah

After all, can't we assume that if the parameter value is a list, then 
it is a group of parameters?


Best,
-jay


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [heat][horizon]Heat UI related requirements roadmap

2013-11-27 Thread Zane Bitter

On 27/11/13 18:16, Tim Schnell wrote:


On 11/27/13 10:09 AM, Zane Bitter zbit...@redhat.com wrote:


On 26/11/13 22:24, Tim Schnell wrote:

Use Case #1
I see valid value in being able to group templates based on a type or


+1, me too.


keyword. This would allow any client, Horizon or a Template Catalog
service, to better organize and handle display options for an end-user.


I believe these are separate use cases and deserve to be elaborated as
such. If one feature can help with both that's great, but we're putting
the cart before the horse if we jump in and implement the feature
without knowing why.

Let's consider first a catalog of operator-provided templates as
proposed (IIUC) by Keith. It seems clear to me in that instance the
keywords are a property of the template's position in the catalog, and
not of the template itself.

Horizon is a slightly different story. Do we even allow people to upload
a bunch of templates and store them in Horizon? If not then there
doesn't seem much point in this feature for current Horizon users. (And
if we do, which would surprise me greatly, then the proposed
implementation doesn't seem that practical - would we want to retrieve
and parse every template to get the keyword?)


Correct, at the moment, Horizon has no concept of a template catalog of
any kind.

Here is my use case for including this in the template for Horizon:
(I'm going to start moving these to the wiki that Steve Baker setup)

Let's assume that an end-user of Heat has spun up 20 stacks and has now
requested help from a Support Operator of heat. In this case, the end-user
did not have a solid naming convention for naming his stacks, they are all
named tim1, tim2, etcŠ And also his request to the Support Operator
was really vague, like My Wordpress stack is broken.

The first thing that the Support Operator would do, would be to pull up
end-user's stacks in either Horizon or via the heat client cli. In both
cases, at the moment, he would then have to either stack-show on each
stack to look at the description of the stack or ask the end-user for a
stack-id/stack-name. This currently gets the job done but a better
experience would be for stack-list to already display some keywords about
each stack so the Support Operator would have to do less digging.

In this case the end-user only has one Wordpress stack so he would have
been annoyed if the Support Operator requested more information from him.
(Or maybe he has more than one wordpress stack, but only one currently in
CREATE_FAILED state).


This is a truly excellent example of a use case, btw. Kudos.


As a team, we have already encountered this exact situation just doing
team testing so I imagine that others would find value in a consistent way
to determine at least a general purpose of a stack, from the stack-list
page. Putting the stack-description in the stack-list table would take up
too much room from a design standpoint.

Once keywords has been added to the template then part of the blueprint
would be to return it with the stack-list information.


Other OpenStack APIs have user-defined 'tags' associated with resources. 
Maybe we should implement something like this for Heat stacks also. 
(i.e. it's in the API, not the template.) When the dashboard launches a 
template out of the template catalog, it could automatically populate 
the tags with the ones from the catalog metadata?



In the longer term, there seems to be a lot of demand for some sort of
template catalog service, like Glance for templates. (I disagree with
Clint that it should actually _be_ Glance the project as we know it, for
the reasons Steve B mentioned earlier, but the concept is right.) And
this brings us back to a very similar situation to the operator-provided
template catalog (indeed, that use case would likely be subsumed by this
one).


I believe that Ladislav initially proposed a solution that will work
here.
So I will second a proposal that we add a new top-level field to the HOT
specification called keywords that contains this template type.

keywords: wordpress, mysql, etcŠ


+1. If we decide that the template is the proper place for these tags
then this is the perfect way to do it IMO (assuming that it's actually a
list, not a comma-separated string). It's a standard format that we can
document and any tool can recognise, the name keywords describes
exactly what it does and there's no confusion with tags in Nova and EC2.


Use Case #2
The template author should also be able to explicitly define a help
string
that is distinct and separate from the description of an individual


This is not a use case, it's a specification. There seems to be a lot of
confusion about the difference, so let me sum it up:

Why - Use Case
What - Specification
How - Design Document (i.e. Code)

I know this all sounds very top-down, and believe me that's not my
philosophy. But design is essentially a global optimisation problem - we
need to see the whole picture to properly 

Re: [openstack-dev] [heat][horizon]Heat UI related requirements roadmap

2013-11-27 Thread Tim Schnell

On 11/27/13 1:17 PM, Zane Bitter zbit...@redhat.com wrote:

On 27/11/13 18:16, Tim Schnell wrote:

 On 11/27/13 10:09 AM, Zane Bitter zbit...@redhat.com wrote:

 On 26/11/13 22:24, Tim Schnell wrote:
 Use Case #1
 I see valid value in being able to group templates based on a type or

 +1, me too.

 keyword. This would allow any client, Horizon or a Template Catalog
 service, to better organize and handle display options for an
end-user.

 I believe these are separate use cases and deserve to be elaborated as
 such. If one feature can help with both that's great, but we're putting
 the cart before the horse if we jump in and implement the feature
 without knowing why.

 Let's consider first a catalog of operator-provided templates as
 proposed (IIUC) by Keith. It seems clear to me in that instance the
 keywords are a property of the template's position in the catalog, and
 not of the template itself.

 Horizon is a slightly different story. Do we even allow people to
upload
 a bunch of templates and store them in Horizon? If not then there
 doesn't seem much point in this feature for current Horizon users. (And
 if we do, which would surprise me greatly, then the proposed
 implementation doesn't seem that practical - would we want to retrieve
 and parse every template to get the keyword?)

 Correct, at the moment, Horizon has no concept of a template catalog of
 any kind.

 Here is my use case for including this in the template for Horizon:
 (I'm going to start moving these to the wiki that Steve Baker setup)

 Let's assume that an end-user of Heat has spun up 20 stacks and has now
 requested help from a Support Operator of heat. In this case, the
end-user
 did not have a solid naming convention for naming his stacks, they are
all
 named tim1, tim2, etcŠ And also his request to the Support Operator
 was really vague, like My Wordpress stack is broken.

 The first thing that the Support Operator would do, would be to pull up
 end-user's stacks in either Horizon or via the heat client cli. In both
 cases, at the moment, he would then have to either stack-show on each
 stack to look at the description of the stack or ask the end-user for a
 stack-id/stack-name. This currently gets the job done but a better
 experience would be for stack-list to already display some keywords
about
 each stack so the Support Operator would have to do less digging.

 In this case the end-user only has one Wordpress stack so he would have
 been annoyed if the Support Operator requested more information from
him.
 (Or maybe he has more than one wordpress stack, but only one currently
in
 CREATE_FAILED state).

This is a truly excellent example of a use case, btw. Kudos.

 As a team, we have already encountered this exact situation just doing
 team testing so I imagine that others would find value in a consistent
way
 to determine at least a general purpose of a stack, from the stack-list
 page. Putting the stack-description in the stack-list table would take
up
 too much room from a design standpoint.

 Once keywords has been added to the template then part of the blueprint
 would be to return it with the stack-list information.

Other OpenStack APIs have user-defined 'tags' associated with resources.
Maybe we should implement something like this for Heat stacks also.
(i.e. it's in the API, not the template.) When the dashboard launches a
template out of the template catalog, it could automatically populate
the tags with the ones from the catalog metadata?

Yeah, I think this is starting to go back to what Angus suggested about
having a tag in the template that is used to associate it back to some
catalog metadata which will work. The only reason I'm pushing for this to
be separate is because then we would be relying on only interfacing with
templates from the catalog for this feature. I think the scope of the
template catalog should be to manage the initial
organization/discoverability of the templates but then once we cross into
what kind of features that we want built in to the stack that is
instantiated, relying on the stack to talk back to the catalog metadata
would exclude this from working for stacks that have been instantiated
from templates that did not come from the catalog.

Do we expect the catalog to be the sole interface for instantiating stacks?


 In the longer term, there seems to be a lot of demand for some sort of
 template catalog service, like Glance for templates. (I disagree with
 Clint that it should actually _be_ Glance the project as we know it,
for
 the reasons Steve B mentioned earlier, but the concept is right.) And
 this brings us back to a very similar situation to the
operator-provided
 template catalog (indeed, that use case would likely be subsumed by
this
 one).

 I believe that Ladislav initially proposed a solution that will work
 here.
 So I will second a proposal that we add a new top-level field to the
HOT
 specification called keywords that contains this template type.

keywords: 

Re: [openstack-dev] [heat][horizon]Heat UI related requirements roadmap

2013-11-27 Thread Clint Byrum
Excerpts from Tim Schnell's message of 2013-11-27 09:16:24 -0800:
 
 On 11/27/13 10:09 AM, Zane Bitter zbit...@redhat.com wrote:
 
 On 26/11/13 22:24, Tim Schnell wrote:
  I propose adding an additional field to the parameter definition:
  
  Parameters:
  parameter name:
  description: This is the name of a nova key pair that will be 
  used to
  ssh to the compute instance.
  help: To learn more about nova key pairs click on this a
  href=/some/url/help article/a.
 
 (Side note: you're seriously going to let users stick HTML in the
 template and then have the dashboard display it?  Yikes.)
 
 FWIW, I said the exact same thing to Keith Bray and his answer was, why
 not?
 

Because it is a cross site scripting problem. You are now allowing users
to publish HTML as your site. If you can guarantee that users will only
ever be shown their own template help, then it is o-k. But that seems
like an unlikely guarantee.

Just use markdown, it has become the standard for these things.

 The UI is already making determinations about what HTML to generate based
 on the template. For example, the parameter label to display just
 unslugifies the parameter key. This is a somewhat tangential discussion
 though, and I do have reservations about it. Maybe Keith can jump in and
 defend this better.
 

Generating HTML is not displaying user input as HTML. There is a rather
large difference.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [heat][horizon]Heat UI related requirements roadmap

2013-11-27 Thread Clint Byrum
Excerpts from Fox, Kevin M's message of 2013-11-27 08:58:16 -0800:
 This use case is sort of a providence case. Where did the stack come from so 
 I can find out more about it.
 

This exhibits similar problems to our Copyright header problems. Relying
on authors to maintain their authorship information in two places is
cumbersome and thus the one that is not automated will likely fall out
of sync fairly quickly.

 You could put a git commit field in the template itself but then it would be 
 hard to keep updated.
 

Or you could have Heat able to pull from any remote source rather than
just allowing submission of the template directly. It would just be
another column in the stack record. This would allow said support person
to see where it came from by viewing the stack, which solves the use case.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [heat][horizon]Heat UI related requirements roadmap

2013-11-27 Thread Clint Byrum
Excerpts from Jay Pipes's message of 2013-11-27 10:57:56 -0800:
 On 11/27/2013 01:28 AM, Clint Byrum wrote:
  I propose adding an additional field to the parameter definition:
 
   Parameters:
   parameter name:
   description: This is the name of a nova key pair that will be 
  used to
  ssh to the compute instance.
   help: To learn more about nova key pairs click on this a
  href=/some/url/help article/a.
 
  +1. A help string per parameter is a fantastic idea. Sounds like a nice
  analog to doc-strings.
 
 Agreed. The above is a nice, straightforward addition.
 
 snip
 
  +1 for grouping. Your use case is perfectly specified above. Love it.
 
  However, your format feels very forced. Integers for ordering? We have
  lists for that.
 
  How about this:
 
  parameters:
 db:
   type: group
   parameters:
 - db_name
 - db_username
 - db_password
 web_node:
   type: group
   parameters:
 - web_node_name
 - keypair
 db_name:
   type: string
 ...
 
  This way we are just providing the groupings outside of the parameters
  themselves. Using a list means the order is as it appears here.
 
 Actually, even simpler than that...
 
 parameters:
db:
 - db_name:
   description: blah
   help: blah
 - db_username:
   description: blah
   help: blah
 
 After all, can't we assume that if the parameter value is a list, then 
 it is a group of parameters?

+1

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [heat][horizon]Heat UI related requirements roadmap

2013-11-27 Thread Zane Bitter

On 27/11/13 19:57, Jay Pipes wrote:


Actually, even simpler than that...

parameters:
   db:
- db_name:
  description: blah
  help: blah
- db_username:
  description: blah
  help: blah

After all, can't we assume that if the parameter value is a list, then
it is a group of parameters?


This resolves to a fairly weird construct:

{
  parameters: {
db: [
  {
db_name: null,
description: blah,
help: blah
  },
  {
description: blah,
db_username: null,
help: blah
  }
]
  }
}

so the name is whichever key has a data value of null (what if there's 
more than one?), and obviously it can't collide with any keywords like 
description or help.


Also, this orders parameters within a group (though not parameters that 
are ungrouped) but not the groups themselves.


cheers,
Zane.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [heat][horizon]Heat UI related requirements roadmap

2013-11-27 Thread Steve Baker
On 11/28/2013 05:09 AM, Zane Bitter wrote:
 On 26/11/13 22:24, Tim Schnell wrote:
 Use Case #1
 I see valid value in being able to group templates based on a type or

 +1, me too.

 keyword. This would allow any client, Horizon or a Template Catalog
 service, to better organize and handle display options for an end-user.

 I believe these are separate use cases and deserve to be elaborated as
 such. If one feature can help with both that's great, but we're
 putting the cart before the horse if we jump in and implement the
 feature without knowing why.

 Let's consider first a catalog of operator-provided templates as
 proposed (IIUC) by Keith. It seems clear to me in that instance the
 keywords are a property of the template's position in the catalog, and
 not of the template itself.

 Horizon is a slightly different story. Do we even allow people to
 upload a bunch of templates and store them in Horizon? If not then
 there doesn't seem much point in this feature for current Horizon
 users. (And if we do, which would surprise me greatly, then the
 proposed implementation doesn't seem that practical - would we want to
 retrieve and parse every template to get the keyword?)

 In the longer term, there seems to be a lot of demand for some sort of
 template catalog service, like Glance for templates. (I disagree with
 Clint that it should actually _be_ Glance the project as we know it,
 for the reasons Steve B mentioned earlier, but the concept is right.)
 And this brings us back to a very similar situation to the
 operator-provided template catalog (indeed, that use case would likely
 be subsumed by this one).

 I believe that Ladislav initially proposed a solution that will work
 here.
 So I will second a proposal that we add a new top-level field to the HOT
 specification called keywords that contains this template type.

 keywords: wordpress, mysql, etcŠ

 +1. If we decide that the template is the proper place for these tags
 then this is the perfect way to do it IMO (assuming that it's actually
 a list, not a comma-separated string). It's a standard format that we
 can document and any tool can recognise, the name keywords describes
 exactly what it does and there's no confusion with tags in Nova and
 EC2.

 Use Case #2
 The template author should also be able to explicitly define a help
 string
 that is distinct and separate from the description of an individual

 This is not a use case, it's a specification. There seems to be a lot
 of confusion about the difference, so let me sum it up:

 Why - Use Case
 What - Specification
 How - Design Document (i.e. Code)

 I know this all sounds very top-down, and believe me that's not my
 philosophy. But design is essentially a global optimisation problem -
 we need to see the whole picture to properly evaluate any given design
 (or, indeed, to find an alternate design), and you're only giving us
 one small piece near the very bottom.

 A use case is something that a user of Heat needs to do.

 An example of a use case would be: The user needs to see two types of
 information in Horizon that are styled differently/shown at different
 times/other (please specify) so that they can __.

 I'm confident that a valid use case _does_ actually exist here, but
 you haven't described it yet.

 parameter. An example where this use case originated was with Nova
 Keypairs. The description of a keypair parameter might be something
 like,
 This is the name of a nova key pair that will be used to ssh to the
 compute instance. A help string for this same parameter would be, To
 learn more about nova keypairs click on this help article.

 It's not at all clear to me that these are different pieces of
 information. They both describe the parameter and they're both there
 to help the user. It would be easier to figure out what the right
 thing would be if you gave an example of what you had in mind for how
 Horizon should display these. Even without that, though, it seems to
 me that the help is just adding more detail to the description.

 One idea I suggested in the review comments is to just interpret the
 first paragraph as the description and any subsequent paragraphs as
 the help. There is ample precedent for that kind of interpretation in
 things like Python docstrings and Git commit messages.
Here is a screenshot of a current horizon stack launch form:
https://www.dropbox.com/s/43imlv2l9nfsj9e/Screenshot%20from%202013-11-28%2011%3A05%3A43.png

Currently the description is used as the field tooltip. The entire right
column isn't really used right now. (I swear it used to show the stack
description.)

Anyway, I could imagine showing the parameter description in the
right-hand column when a field gains focus, and the help string being
used for the tooltip instead.


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [heat][horizon]Heat UI related requirements roadmap

2013-11-27 Thread Jay Pipes

On 11/27/2013 04:56 PM, Zane Bitter wrote:

On 27/11/13 19:57, Jay Pipes wrote:


Actually, even simpler than that...

parameters:
   db:
- db_name:
  description: blah
  help: blah
- db_username:
  description: blah
  help: blah

After all, can't we assume that if the parameter value is a list, then
it is a group of parameters?


This resolves to a fairly weird construct:

{
   parameters: {
 db: [
   {
 db_name: null,
 description: blah,
 help: blah
   },
   {
 description: blah,
 db_username: null,
 help: blah
   }
 ]
   }
}

so the name is whichever key has a data value of null (what if there's
more than one?), and obviously it can't collide with any keywords like
description or help.


I think I was going for more of the YAML that would resolve to this:

{
parameters: {
 db: [
  {
   db_name: {
description: blah,
help: blah
   }
  },
  {
   db_username: {
description: blah,
help: blah
   }
  },
 ]
}

Best,
-jay

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [heat][horizon]Heat UI related requirements roadmap

2013-11-27 Thread Fox, Kevin M
Hmm... Yeah. when you tell heat client the url to a template file, you could 
set a flag telling the heat client it is in a git repo. It could then 
automatically look for repo information and set a stack metadata item pointing 
back to it.

If you didn't care about taking a performance hit, heat client could always try 
and check to see if it was a git repo url. That may add several extra http 
requests though...

Thanks,
Kevin

From: Clint Byrum [cl...@fewbar.com]
Sent: Wednesday, November 27, 2013 1:04 PM
To: openstack-dev
Subject: Re: [openstack-dev] [heat][horizon]Heat UI related requirements   
roadmap

Excerpts from Fox, Kevin M's message of 2013-11-27 08:58:16 -0800:
 This use case is sort of a providence case. Where did the stack come from so 
 I can find out more about it.


This exhibits similar problems to our Copyright header problems. Relying
on authors to maintain their authorship information in two places is
cumbersome and thus the one that is not automated will likely fall out
of sync fairly quickly.

 You could put a git commit field in the template itself but then it would be 
 hard to keep updated.


Or you could have Heat able to pull from any remote source rather than
just allowing submission of the template directly. It would just be
another column in the stack record. This would allow said support person
to see where it came from by viewing the stack, which solves the use case.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [heat][horizon]Heat UI related requirements roadmap

2013-11-27 Thread Tim Schnell

On 11/27/13 4:12 PM, Steve Baker sba...@redhat.com wrote:

On 11/28/2013 05:09 AM, Zane Bitter wrote:
 On 26/11/13 22:24, Tim Schnell wrote:
 Use Case #1
 I see valid value in being able to group templates based on a type or

 +1, me too.

 keyword. This would allow any client, Horizon or a Template Catalog
 service, to better organize and handle display options for an end-user.

 I believe these are separate use cases and deserve to be elaborated as
 such. If one feature can help with both that's great, but we're
 putting the cart before the horse if we jump in and implement the
 feature without knowing why.

 Let's consider first a catalog of operator-provided templates as
 proposed (IIUC) by Keith. It seems clear to me in that instance the
 keywords are a property of the template's position in the catalog, and
 not of the template itself.

 Horizon is a slightly different story. Do we even allow people to
 upload a bunch of templates and store them in Horizon? If not then
 there doesn't seem much point in this feature for current Horizon
 users. (And if we do, which would surprise me greatly, then the
 proposed implementation doesn't seem that practical - would we want to
 retrieve and parse every template to get the keyword?)

 In the longer term, there seems to be a lot of demand for some sort of
 template catalog service, like Glance for templates. (I disagree with
 Clint that it should actually _be_ Glance the project as we know it,
 for the reasons Steve B mentioned earlier, but the concept is right.)
 And this brings us back to a very similar situation to the
 operator-provided template catalog (indeed, that use case would likely
 be subsumed by this one).

 I believe that Ladislav initially proposed a solution that will work
 here.
 So I will second a proposal that we add a new top-level field to the
HOT
 specification called keywords that contains this template type.

 keywords: wordpress, mysql, etcŠ

 +1. If we decide that the template is the proper place for these tags
 then this is the perfect way to do it IMO (assuming that it's actually
 a list, not a comma-separated string). It's a standard format that we
 can document and any tool can recognise, the name keywords describes
 exactly what it does and there's no confusion with tags in Nova and
 EC2.

 Use Case #2
 The template author should also be able to explicitly define a help
 string
 that is distinct and separate from the description of an individual

 This is not a use case, it's a specification. There seems to be a lot
 of confusion about the difference, so let me sum it up:

 Why - Use Case
 What - Specification
 How - Design Document (i.e. Code)

 I know this all sounds very top-down, and believe me that's not my
 philosophy. But design is essentially a global optimisation problem -
 we need to see the whole picture to properly evaluate any given design
 (or, indeed, to find an alternate design), and you're only giving us
 one small piece near the very bottom.

 A use case is something that a user of Heat needs to do.

 An example of a use case would be: The user needs to see two types of
 information in Horizon that are styled differently/shown at different
 times/other (please specify) so that they can __.

 I'm confident that a valid use case _does_ actually exist here, but
 you haven't described it yet.

 parameter. An example where this use case originated was with Nova
 Keypairs. The description of a keypair parameter might be something
 like,
 This is the name of a nova key pair that will be used to ssh to the
 compute instance. A help string for this same parameter would be, To
 learn more about nova keypairs click on this help article.

 It's not at all clear to me that these are different pieces of
 information. They both describe the parameter and they're both there
 to help the user. It would be easier to figure out what the right
 thing would be if you gave an example of what you had in mind for how
 Horizon should display these. Even without that, though, it seems to
 me that the help is just adding more detail to the description.

 One idea I suggested in the review comments is to just interpret the
 first paragraph as the description and any subsequent paragraphs as
 the help. There is ample precedent for that kind of interpretation in
 things like Python docstrings and Git commit messages.
Here is a screenshot of a current horizon stack launch form:
https://www.dropbox.com/s/43imlv2l9nfsj9e/Screenshot%20from%202013-11-28%2
011%3A05%3A43.png

Currently the description is used as the field tooltip. The entire right
column isn't really used right now. (I swear it used to show the stack
description.)

Anyway, I could imagine showing the parameter description in the
right-hand column when a field gains focus, and the help string being
used for the tooltip instead.

+1 Yes, this is a great illustration of how I would expect the 2 fields to
be used.

Thanks Steve!
Tim



Re: [openstack-dev] [heat][horizon]Heat UI related requirements roadmap

2013-11-27 Thread Tim Schnell
I have created the following wiki with all of the related use cases that
have been discussed in this thread as well as where I think we have
currently landed on the actual implementation for these use cases.

https://wiki.openstack.org/wiki/Heat/UI


I know that the first use case in particular, regarding keywords, seems to
still need a bit of discussion so feel free to add to the wiki if needed.

I'll be out for the holiday until Monday so I won't be responding as
heavily to this discussion until then but I'll look to start the
blueprints for these use cases next week.

Thanks again for the feedback, it is very important to have the Heat
communities input for the end-user experience and I feel like we have
already made tremendous strides in the right direction.

Thanks,
Tim


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [heat][horizon]Heat UI related requirements roadmap

2013-11-27 Thread Thomas Spatzier
Zane Bitter zbit...@redhat.com wrote on 27.11.2013 22:56:16:

 From: Zane Bitter zbit...@redhat.com
 To: openstack-dev@lists.openstack.org,
 Date: 27.11.2013 23:00
 Subject: Re: [openstack-dev] [heat][horizon]Heat UI related
 requirements  roadmap

 On 27/11/13 19:57, Jay Pipes wrote:
 
  Actually, even simpler than that...
 
  parameters:
 db:
  - db_name:
description: blah
help: blah
  - db_username:
description: blah
help: blah
 
  After all, can't we assume that if the parameter value is a list, then
  it is a group of parameters?

 This resolves to a fairly weird construct:

 {
parameters: {
  db: [
{
  db_name: null,
  description: blah,
  help: blah
},
{
  description: blah,
  db_username: null,
  help: blah
}
  ]
}
 }

 so the name is whichever key has a data value of null (what if there's
 more than one?), and obviously it can't collide with any keywords like
 description or help.

 Also, this orders parameters within a group (though not parameters that
 are ungrouped) but not the groups themselves.

Agree that this is kind of a strange construct. I would be more in favor of
(1) making parameters a list which bring implicit ordering (so is intuitive
to the user, and (2) adding the grouping as a separate thing.

E.g.

parameters:
  - db_user:
  type: string
  description: DB user name.
  - db_password:
  type: string
  description: DB password.
  - app_user:
  type: string
  description: Application user name.
  - app_password:
  type: string
  description: application password.

parameter_groups:
  - db: [ db_user, db_password ]
description: Database parameters.
  - app: [ app_user, app_password ]
description: Application parameters.



 cheers,
 Zane.

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [heat][horizon]Heat UI related requirements roadmap

2013-11-26 Thread Ladislav Smola

Hello,

seems too big to do the inline comments, so just a few notes here:

If we truly want to have Templates portable, it would mean to have the 
'metadata' somehow standardised, right?
Otherwise if every UI will add their own metadata, then I hardly see the 
templates as portable. I think first step would be then to delete
the metadata and add your own, unless you are fine to have 80% of the 
template some metadata you don't use. That also won't

help the readability. What will help a readability are the verbose comments.

I am not really sure how long it can take to add new specialized tags, 
that are used only in Horizon and are well documented. I think showing
this, should get the patch merged very quickly. That seems to me like a 
portable solution.


IMO for the template catalogue we would probably need a new service, 
something like Glance, so that's probably a more distant future.


For the use-cases:
---

ad 1)
Something more general next to Description may be more useful, like 
keywords, packages or components.

Example:

Description...
Keywords: wordpress, mysql...

Or you could parse it from e.g. packages (though that is not always 
used, so being able to write it explicitly might be handy)


ad 2)
Maybe adding something like 'author' tag may be a good idea, though you 
can find all the history in git repo,
given you use https://github.com/openstack/heat-templates . If you have 
different repo, adding something like

Origin: https://github.com/openstack/heat-templates maybe?

ad 3)
So having a fix and documented schema seems to be a good way to be 
portable, at least to me. I am not
against UI only tags inside the template, that are really useful for 
everybody. We will find out by collectively

reviewing that, which usually brings some easier solution.

Or you don't think, it will get too wild to have some 'metadata' section 
completely ignored by Heat? Seems
to me like there will be a lot of cases, when people won't push their 
template to upstream, because of the
metadata they have added to their templates, that nobody else will ever 
use. Is somebody else concerned

about this?

That's my 2 cents.

Kind regards,
Ladislav


On 11/26/2013 07:32 AM, Keith Bray wrote:
Thanks Steve.  I appreciate your input. I have added the use cases for 
all to review:

https://wiki.openstack.org/wiki/Heat/StackMetadata

What are next steps to drive this to resolution?

Kind regards,
-Keith

From: Steve Baker sba...@redhat.com mailto:sba...@redhat.com
Reply-To: OpenStack Development Mailing List (not for usage 
questions) openstack-dev@lists.openstack.org 
mailto:openstack-dev@lists.openstack.org

Date: Monday, November 25, 2013 11:47 PM
To: openstack-dev@lists.openstack.org 
mailto:openstack-dev@lists.openstack.org 
openstack-dev@lists.openstack.org 
mailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [heat][horizon]Heat UI related 
requirements  roadmap


On 11/26/2013 03:26 PM, Keith Bray wrote:

On 11/25/13 5:46 PM, Clint Byrumcl...@fewbar.com  wrote:


Excerpts from Tim Schnell's message of 2013-11-25 14:51:39 -0800:

Hi Steve,

As one of the UI developers driving the requirements behind these new
blueprints I wanted to take a moment to assure you and the rest of the
Openstack community that the primary purpose of pushing these
requirements
out to the community is to help improve the User Experience for Heat for
everyone. Every major UI feature that I have implemented for Heat has
been
included in Horizon, see the Heat Topology, and these requirements
should
improve the value of Heat, regardless of the UI.


Stack/template metadata
We have a fundamental need to have the ability to reference some
additional metadata about a template that Heat does not care about.
There
are many possible use cases for this need but the primary point is that
we
need a place in the template where we can iterate on the schema of the
metadata without going through a lengthy design review. As far as I
know,
we are the only team attempting to actually productize Heat at the
moment
and this means that we are encountering requirements and requests that
do
not affect Heat directly but simply require Heat to allow a little
wiggle
room to flesh out a great user experience.


Wiggle room is indeed provided. But reviewers need to understand your
motivations, which is usually what blueprints are used for. If you're
getting push back, it is likely because your blueprints to not make the
use cases and long term vision obvious.

Clint, can you be more specific on what is not clear about the use case?
What I am seeing is that the use case of meta data is not what is being
contested, but that the Blueprint of where meta data should go is being
contested by only a few (but not all) of the core devs.  The Blueprint for
in-template metadata was already approved for Icehouse, but now that work
has been delivered on the implementation of that blueprint, the blueprint
itself is being contested:
https

Re: [openstack-dev] [heat][horizon]Heat UI related requirements roadmap

2013-11-26 Thread Steven Hardy
On Tue, Nov 26, 2013 at 03:04:12PM +0100, Ladislav Smola wrote:
 Hello,
 
 seems too big to do the inline comments, so just a few notes here:
 
 If we truly want to have Templates portable, it would mean to have
 the 'metadata' somehow standardised, right?
 Otherwise if every UI will add their own metadata, then I hardly see
 the templates as portable. I think first step would be then to
 delete
 the metadata and add your own, unless you are fine to have 80% of
 the template some metadata you don't use. That also won't
 help the readability. What will help a readability are the verbose comments.

I completely agree, and allowing free-form metadata will invariably tempt
some folks to implement other provider specific stuff besides the UI in the
metadata block, which is obviously really bad for cross-provider
template portability.

 I am not really sure how long it can take to add new specialized
 tags, that are used only in Horizon and are well documented. I think
 showing
 this, should get the patch merged very quickly. That seems to me
 like a portable solution.

Yes - I'm not opposed to having metadata in the template which is useful to
users, I'm opposed to having a provider-specific magic-metadata block.

 IMO for the template catalogue we would probably need a new service,
 something like Glance, so that's probably a more distant future.
 
 For the use-cases:
 ---
 
 ad 1)
 Something more general next to Description may be more useful, like
 keywords, packages or components.
 Example:
 
 Description...
 Keywords: wordpress, mysql...

+1, I was thinking tags, but keywords works too and is possibly clearer.

 ad 2)
 Maybe adding something like 'author' tag may be a good idea, though
 you can find all the history in git repo,
 given you use https://github.com/openstack/heat-templates . If you
 have different repo, adding something like
 Origin: https://github.com/openstack/heat-templates maybe?

Yep, adding an optional author and creation_date would probably be OK,
although it's a slippery slope towards duplicating all the info already
available in a revision control system.

As you say, all the info is in git (which is what I've been arguing since
we started discussing this in HK)

If we added a keyword which could contain a string related to the exact
template version, would that solve this use-case?

It could be origin, source, whatever, but you could then specify any
identifier you want, a URL containing the git SHA would probably be a good
plan, e.g:

https://raw.github.com/openstack/heat-templates/623ee7fa04492772eeae1fa5559802eabd11558e/hot/F18/WordPress_Native.yaml

This then tells you much more than some static in-template metadata can:
- Where the template came from
- What version it is
- All the history related to modifications and who wrote it etc.

More stuff like who to wake up when it breaks could easily be added as git
notes, and you gain the capability to expose different data to
users/operators/admins without having to put it all in the template (the
unique URL could be visible to users, but not necessarily the git repo with
all the data if a provider wants to publish templates but not the repo)

 ad 3)
 So having a fix and documented schema seems to be a good way to be
 portable, at least to me. I am not
 against UI only tags inside the template, that are really useful for
 everybody. We will find out by collectively
 reviewing that, which usually brings some easier solution.
 
 Or you don't think, it will get too wild to have some 'metadata'
 section completely ignored by Heat? Seems
 to me like there will be a lot of cases, when people won't push
 their template to upstream, because of the
 metadata they have added to their templates, that nobody else will
 ever use. Is somebody else concerned
 about this?

Yes, you've summarised my own concerns pretty well there.

Steve

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [heat][horizon]Heat UI related requirements roadmap

2013-11-26 Thread Zane Bitter

On 26/11/13 03:26, Keith Bray wrote:



On 11/25/13 5:46 PM, Clint Byrum cl...@fewbar.com wrote:


Excerpts from Tim Schnell's message of 2013-11-25 14:51:39 -0800:

Hi Steve,

As one of the UI developers driving the requirements behind these new
blueprints I wanted to take a moment to assure you and the rest of the
Openstack community that the primary purpose of pushing these
requirements
out to the community is to help improve the User Experience for Heat for
everyone. Every major UI feature that I have implemented for Heat has
been
included in Horizon, see the Heat Topology, and these requirements
should
improve the value of Heat, regardless of the UI.


Stack/template metadata
We have a fundamental need to have the ability to reference some
additional metadata about a template that Heat does not care about.
There
are many possible use cases for this need but the primary point is that
we
need a place in the template where we can iterate on the schema of the
metadata without going through a lengthy design review. As far as I
know,
we are the only team attempting to actually productize Heat at the
moment
and this means that we are encountering requirements and requests that
do
not affect Heat directly but simply require Heat to allow a little
wiggle
room to flesh out a great user experience.



Wiggle room is indeed provided. But reviewers need to understand your
motivations, which is usually what blueprints are used for. If you're
getting push back, it is likely because your blueprints to not make the
use cases and long term vision obvious.


Clint, can you be more specific on what is not clear about the use case?


The part where it's used for something. What I'm hearing in this thread 
is We need this for a template catalog, but we're not going to talk 
about that until later. Trust us, though, we really need it.


That's a problem, because none of this stuff makes sense except in the 
context of the template catalog. What does the template catalog do? Who 
writes the templates in the catalog? Why is the template catalog not 
backed by git? Who can say which parts of the solution belong in the 
template catalog and which in Heat when we don't even know what it's a 
solution to?



What I am seeing is that the use case of meta data is not what is being


I'm contesting it:

https://review.openstack.org/#/c/56703/7/doc/source/template_guide/hot_spec.rst

The problem here isn't that the process wasn't followed, it's that all 
of these things - one-shot outputs, operator-specific structured 
metadata sections in templates, APIs to report versions of randomly 
selected daemons - are fundamentally bad ideas. And they're all bad in 
exactly the same way: they demand that Heat implement something that it 
can only do in a half-baked manner, because it's slightly easier (or 
seems slightly easier) than implementing something in some external tool 
that can work.


It's difficult to escape the conclusion that these features have been 
decided upon behind closed doors with the community excluded, by people 
who are not especially familiar with Heat, with a view to minimising the 
effort required to implement some other (proprietary?) thing and not 
necessarily to coming up with the best implementation. If this is your 
development process then you are Doing Open Source Wrong. At a very 
minimum you need to work about 10x harder to explain all of these design 
decisions - in particular the reasons why the obvious alternatives that 
don't appear to have been considered are insufficient - to the 
community. It's much, much easier, though, to just do your design in the 
open with community involvement.


Take this metadata section idea. (Please!) Let's step back and examine 
the very last decision in the chain - assume for a moment that we accept 
that this metadata needs to be included in the template. There are three 
obvious ways to do that:


 1) Include them as YAML comments
 2) Include them in the body of the template
 3) Include them as a separate YAML document in the same file

How many of those were actually considered? My bet is only #2. It 
doesn't really matter though, because there is not one word of design 
documentation that would help me understand the reasons for rejecting #1 
 #3 (neither of which require any changes to Heat or the template 
format). How can I have confidence that #2 is the correct solution to 
the problem? Especially if I don't agree (I don't)?


The number of options not considered grows (and my confidence in the 
solution shrinks) exponentially as you step all the way back through the 
chain of undocumented decisions to the actual thing that drove this idea.



contested, but that the Blueprint of where meta data should go is being
contested by only a few (but not all) of the core devs.  The Blueprint for


I contested that first because without knowing what the feature is even 
for, there's nothing else to contest.



in-template metadata was already approved for Icehouse, but 

Re: [openstack-dev] [heat][horizon]Heat UI related requirements roadmap

2013-11-26 Thread Tim Schnell
So the originally question that I attempted to pose was, Can we add a
schema-less metadata section to the template that can be used for a
variety of purposes?. It looks like the answer is no, we need to discuss
the features that would go in the metadata section and add them to the HOT
specification if they are viable. I don't necessarily agree with this
answer but I accept it as viable and take responsibility for the
long-winded process that it took to get to this point.

I think some valid points have been made and I have re-focused my efforts
into the following proposed solution.

I am fine with getting rid of the concept of a schema-less metadata
section. If we can arrive at a workable design for a few use cases then I
think that we won't need to discuss any of the options that Zane mentioned
for handling the metadata section, comments, separate file, or in the
template body.

Use Case #1
I see valid value in being able to group templates based on a type or
keyword. This would allow any client, Horizon or a Template Catalog
service, to better organize and handle display options for an end-user.

I believe that Ladislav initially proposed a solution that will work here.
So I will second a proposal that we add a new top-level field to the HOT
specification called keywords that contains this template type.

keywords: wordpress, mysql, etcŠ


Use Case #2
The template author should also be able to explicitly define a help string
that is distinct and separate from the description of an individual
parameter. An example where this use case originated was with Nova
Keypairs. The description of a keypair parameter might be something like,
This is the name of a nova key pair that will be used to ssh to the
compute instance. A help string for this same parameter would be, To
learn more about nova keypairs click on this help article.

I propose adding an additional field to the parameter definition:

Parameters:
parameter name:
description: This is the name of a nova key pair that 
will be used to
ssh to the compute instance.
help: To learn more about nova key pairs click on this 
a
href=/some/url/help article/a.

Use Case #3
Grouping parameters would help the client make smarter decisions about how
to display the parameters for input to the end-user. This is so that all
parameters related to some database resource can be intelligently grouped
together. In addition to grouping these parameters together, there should
be a method to ensuring that the order within the group of parameters can
be explicitly stated. This way, the client can return a group of database
parameters and the template author can indicate that the database instance
name should be first, then the username, then the password, instead of
that group being returned in a random order.

Parameters:
db_name:
group: db
order: 0
db_username:
group: db
order: 1
db_password:
group: db
order: 2
web_node_name:
group: web_node
order: 0
keypair:
group: web_node
order: 1

These are the use cases that have been clearly defined. The original
purpose of the metadata section was to future-proof (I say future-proof,
you say pre-optimize ;) ) rapid iterations to potential client design. The
intent of the strategy was so that we did not overburden the Heat Core
team with requirements that may fluctuate or change as we attempt to
improve the user experience of Heat for the community. In hindsight I can
see how that intent was misconstrued and may have come off as
condescending and I apologize for that.

I think that these proposed use cases will add real value to Heat and
would require only changes to the HOT specification. If these are
acceptable please let me know and I will drop the existing blueprint and
patches in favor of something that implements this design. If there are
issues to discuss here please suggest alternative solutions so that we can
continue to move forward with these improvements.

I have no doubt that this is just the beginning of plenty of requirements
being driven from an attempt to improve the overall end user experience of
Heat and I will continue to vet the use cases and proposed implementations
with the community before suggesting a solution. I know that this proposal
leaves out a few use cases that have been discussed like template
author/version and that is because I believe that some of the arguments
made are valid and should be looked into before proposing changes to Heat.
Most of those other use cases probably can be served from some other
solution like git or the future template catalog.

Thanks, 
Tim





On 11/26/13 12:31 PM, 

Re: [openstack-dev] [heat][horizon]Heat UI related requirements roadmap

2013-11-26 Thread Christopher Armstrong
On Tue, Nov 26, 2013 at 3:24 PM, Tim Schnell tim.schn...@rackspace.comwrote:

 So the originally question that I attempted to pose was, Can we add a
 schema-less metadata section to the template that can be used for a
 variety of purposes?. It looks like the answer is no, we need to discuss
 the features that would go in the metadata section and add them to the HOT
 specification if they are viable. I don't necessarily agree with this
 answer but I accept it as viable and take responsibility for the
 long-winded process that it took to get to this point.

 I think some valid points have been made and I have re-focused my efforts
 into the following proposed solution.

 I am fine with getting rid of the concept of a schema-less metadata
 section. If we can arrive at a workable design for a few use cases then I
 think that we won't need to discuss any of the options that Zane mentioned
 for handling the metadata section, comments, separate file, or in the
 template body.

 Use Case #1
 I see valid value in being able to group templates based on a type or
 keyword. This would allow any client, Horizon or a Template Catalog
 service, to better organize and handle display options for an end-user.

 I believe that Ladislav initially proposed a solution that will work here.
 So I will second a proposal that we add a new top-level field to the HOT
 specification called keywords that contains this template type.

 keywords: wordpress, mysql, etc



My immediate inclination would be to just make keywords/tags out-of-band
metadata managed by the template repository. I imagine this would be
something that would be very useful to change without having to edit the
template anyway.



 Use Case #2
 The template author should also be able to explicitly define a help string
 that is distinct and separate from the description of an individual
 parameter. An example where this use case originated was with Nova
 Keypairs. The description of a keypair parameter might be something like,
 This is the name of a nova key pair that will be used to ssh to the
 compute instance. A help string for this same parameter would be, To
 learn more about nova keypairs click on this help article.

 I propose adding an additional field to the parameter definition:

 Parameters:
 parameter name:
 description: This is the name of a nova key pair
 that will be used to
 ssh to the compute instance.
 help: To learn more about nova key pairs click on
 this a
 href=/some/url/help article/a.


This one seems a bit weirder. I don't really understand what's wrong with
just adding this content to the description field. However, if there are
currently any objects in HOT that don't have any mechanism for providing a
description, we should definitely add them where they're missing. Do you
think we need to extend the semantics of the description field to allow
HTML?



 Use Case #3
 Grouping parameters would help the client make smarter decisions about how
 to display the parameters for input to the end-user. This is so that all
 parameters related to some database resource can be intelligently grouped
 together. In addition to grouping these parameters together, there should
 be a method to ensuring that the order within the group of parameters can
 be explicitly stated. This way, the client can return a group of database
 parameters and the template author can indicate that the database instance
 name should be first, then the username, then the password, instead of
 that group being returned in a random order.

 Parameters:
 db_name:
 group: db
 order: 0
 db_username:
 group: db
 order: 1
 db_password:
 group: db
 order: 2
 web_node_name:
 group: web_node
 order: 0
 keypair:
 group: web_node
 order: 1




Have you considered just rendering them in the order that they appear in
the template? I realize it's not the name (since you don't have any group
names that you could use as a title for boxes around groups of
parameters), but it might be a good enough compromise. If you think it's
absolutely mandatory to be able to group them in named groups, then I would
actually propose a prettier syntax:

ParameterGroups:
db:
name: ...
username: ...
password: ...
web_node:
name: ...
keypair: ...

The ordering would be based on the ordering that they appear within the
template, and you wouldn't have to repeat yourself naming the group for
each parameter.

Thanks very much for writing up these use cases!

-- 
IRC: radix
Christopher Armstrong
Rackspace
___
OpenStack-dev mailing 

Re: [openstack-dev] [heat][horizon]Heat UI related requirements roadmap

2013-11-26 Thread Steve Baker
On 11/27/2013 11:02 AM, Christopher Armstrong wrote:
 On Tue, Nov 26, 2013 at 3:24 PM, Tim Schnell
 tim.schn...@rackspace.com mailto:tim.schn...@rackspace.com wrote:

  

 Use Case #3
 Grouping parameters would help the client make smarter decisions
 about how
 to display the parameters for input to the end-user. This is so
 that all
 parameters related to some database resource can be intelligently
 grouped
 together. In addition to grouping these parameters together, there
 should
 be a method to ensuring that the order within the group of
 parameters can
 be explicitly stated. This way, the client can return a group of
 database
 parameters and the template author can indicate that the database
 instance
 name should be first, then the username, then the password, instead of
 that group being returned in a random order.

 Parameters:
 db_name:
 group: db
 order: 0
 db_username:
 group: db
 order: 1
 db_password:
 group: db
 order: 2
 web_node_name:
 group: web_node
 order: 0
 keypair:
 group: web_node
 order: 1




 Have you considered just rendering them in the order that they appear
 in the template? I realize it's not the name (since you don't have any
 group names that you could use as a title for boxes around groups of
 parameters), but it might be a good enough compromise. If you think
 it's absolutely mandatory to be able to group them in named groups,
 then I would actually propose a prettier syntax:

 ParameterGroups:
 db:
 name: ...
 username: ...
 password: ...
 web_node:
 name: ...
 keypair: ...

 The ordering would be based on the ordering that they appear within
 the template, and you wouldn't have to repeat yourself naming the
 group for each parameter.

 Thanks very much for writing up these use cases!

Good point, I'd like to revise my previous parameter-groups example:

parameter-groups:
- name: db
  description: Database configuration options
  parameters: [db_name, db_username, db_password]
- name: web_node
  description: Web server configuration
  parameters: [web_node_name, keypair]
parameters:
  # as above, but without requiring any order or group attributes

Here, parameter-groups is a list which implies the order, and parameters are 
specified in the group as a list, so we get the order from that too. This means 
a new parameter-groups section which contains anything required to build a good 
parameters form, and no modifications required to the parameters section at 
all. 


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [heat][horizon]Heat UI related requirements roadmap

2013-11-26 Thread Tim Schnell

From: Steve Baker sba...@redhat.commailto:sba...@redhat.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Tuesday, November 26, 2013 4:29 PM
To: 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [heat][horizon]Heat UI related requirements  
roadmap

On 11/27/2013 11:02 AM, Christopher Armstrong wrote:
On Tue, Nov 26, 2013 at 3:24 PM, Tim Schnell 
tim.schn...@rackspace.commailto:tim.schn...@rackspace.com wrote:


Use Case #3
Grouping parameters would help the client make smarter decisions about how
to display the parameters for input to the end-user. This is so that all
parameters related to some database resource can be intelligently grouped
together. In addition to grouping these parameters together, there should
be a method to ensuring that the order within the group of parameters can
be explicitly stated. This way, the client can return a group of database
parameters and the template author can indicate that the database instance
name should be first, then the username, then the password, instead of
that group being returned in a random order.

Parameters:
db_name:
group: db
order: 0
db_username:
group: db
order: 1
db_password:
group: db
order: 2
web_node_name:
group: web_node
order: 0
keypair:
group: web_node
order: 1




Have you considered just rendering them in the order that they appear in the 
template? I realize it's not the name (since you don't have any group names 
that you could use as a title for boxes around groups of parameters), but it 
might be a good enough compromise. If you think it's absolutely mandatory to be 
able to group them in named groups, then I would actually propose a prettier 
syntax:

ParameterGroups:
db:
name: ...
username: ...
password: ...
web_node:
name: ...
keypair: ...

The ordering would be based on the ordering that they appear within the 
template, and you wouldn't have to repeat yourself naming the group for each 
parameter.

Thanks very much for writing up these use cases!

Good point, I'd like to revise my previous parameter-groups example:

parameter-groups:
- name: db
  description: Database configuration options
  parameters: [db_name, db_username, db_password]
- name: web_node
  description: Web server configuration
  parameters: [web_node_name, keypair]
parameters:
  # as above, but without requiring any order or group attributes

Here, parameter-groups is a list which implies the order, and parameters are 
specified in the group as a list, so we get the order from that too. This means 
a new parameter-groups section which contains anything required to build a good 
parameters form, and no modifications required to the parameters section at all.


+1 This structure gives me all of the information that I would need for 
organizing the parameters on the screen in an exact way.

Thanks,
Tim

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [heat][horizon]Heat UI related requirements roadmap

2013-11-26 Thread Christopher Armstrong
On Tue, Nov 26, 2013 at 4:35 PM, Tim Schnell tim.schn...@rackspace.comwrote:


From: Christopher Armstrong chris.armstr...@rackspace.com

 Reply-To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Date: Tuesday, November 26, 2013 4:02 PM

 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [heat][horizon]Heat UI related requirements
  roadmap

On Tue, Nov 26, 2013 at 3:24 PM, Tim Schnell tim.schn...@rackspace.com
  wrote:

 So the originally question that I attempted to pose was, Can we add a
 schema-less metadata section to the template that can be used for a
 variety of purposes?. It looks like the answer is no, we need to discuss
 the features that would go in the metadata section and add them to the HOT
 specification if they are viable. I don't necessarily agree with this
 answer but I accept it as viable and take responsibility for the
 long-winded process that it took to get to this point.

 I think some valid points have been made and I have re-focused my efforts
 into the following proposed solution.

 I am fine with getting rid of the concept of a schema-less metadata
 section. If we can arrive at a workable design for a few use cases then I
 think that we won't need to discuss any of the options that Zane mentioned
 for handling the metadata section, comments, separate file, or in the
 template body.

 Use Case #1
 I see valid value in being able to group templates based on a type or
 keyword. This would allow any client, Horizon or a Template Catalog
 service, to better organize and handle display options for an end-user.

 I believe that Ladislav initially proposed a solution that will work here.
 So I will second a proposal that we add a new top-level field to the HOT
 specification called keywords that contains this template type.

 keywords: wordpress, mysql, etc



  My immediate inclination would be to just make keywords/tags out-of-band
 metadata managed by the template repository. I imagine this would be
 something that would be very useful to change without having to edit the
 template anyway.

  *I'm not exactly sure what you are suggesting here, but I think that
 adding these keywords to the template will be less error prone than
 attempting to derive them some other way.*


Basically, I'm just suggesting putting the tags outside of template. Not
deriving them -- I still think they should be explicitly specified, but
just putting them in e.g. the database instead of directly in the template.

Basically, in a public repository of templates, I can imagine tags being
based on third-party or moderator input, instead of just based on what the
template author says.  Keeping them outside of the template would allow
content moderators to do that without posting a new version of the template.

Anyway, I don't feel that strongly about this - if there's a strong enough
desire to see tags in the template, then I won't argue against it.





 Use Case #2
 The template author should also be able to explicitly define a help string
 that is distinct and separate from the description of an individual
 parameter. An example where this use case originated was with Nova
 Keypairs. The description of a keypair parameter might be something like,
 This is the name of a nova key pair that will be used to ssh to the
 compute instance. A help string for this same parameter would be, To
 learn more about nova keypairs click on this help article.

 I propose adding an additional field to the parameter definition:

 Parameters:
 parameter name:
 description: This is the name of a nova key pair
 that will be used to
 ssh to the compute instance.
 help: To learn more about nova key pairs click on
 this a
 href=/some/url/help article/a.


  This one seems a bit weirder. I don't really understand what's wrong
 with just adding this content to the description field. However, if there
 are currently any objects in HOT that don't have any mechanism for
 providing a description, we should definitely add them where they're
 missing. Do you think we need to extend the semantics of the description
 field to allow HTML?

  *Description and help are separate things from a UI perspective. A
 description might be displayed as a label in a form or in a paragraph
 somewhere around the input. A help string is typically displayed as hover
 text when focusing on the input or hovering/clicking on a question mark
 icon next to the field. We could technically separate these things in the
 code but because they serve separate purposes I would prefer to have them
 be defined explicitly.*


Okay, fair enough.





 Use Case #3
 Grouping parameters would help the client make smarter decisions about how
 to display the parameters for input to the end-user. This is so that all
 parameters related to some database resource can

Re: [openstack-dev] [heat][horizon]Heat UI related requirements roadmap

2013-11-26 Thread Tim Schnell

On 11/26/13 4:16 PM, Steve Baker sba...@redhat.com wrote:

On 11/27/2013 10:24 AM, Tim Schnell wrote:
 So the originally question that I attempted to pose was, Can we add a
 schema-less metadata section to the template that can be used for a
 variety of purposes?. It looks like the answer is no, we need to
discuss
 the features that would go in the metadata section and add them to the
HOT
 specification if they are viable. I don't necessarily agree with this
 answer but I accept it as viable and take responsibility for the
 long-winded process that it took to get to this point.

 I think some valid points have been made and I have re-focused my
efforts
 into the following proposed solution.

 I am fine with getting rid of the concept of a schema-less metadata
 section. If we can arrive at a workable design for a few use cases then
I
 think that we won't need to discuss any of the options that Zane
mentioned
 for handling the metadata section, comments, separate file, or in the
 template body.

 Use Case #1
 I see valid value in being able to group templates based on a type or
 keyword. This would allow any client, Horizon or a Template Catalog
 service, to better organize and handle display options for an end-user.

 I believe that Ladislav initially proposed a solution that will work
here.
 So I will second a proposal that we add a new top-level field to the HOT
 specification called keywords that contains this template type.

  keywords: wordpress, mysql, etcŠ
+1, but lets make the most of yaml and give it structure:
keywords: [wordpress, mysql, lamp]
keywords:
- wordpress
- mysql
- lamp


 Use Case #2
 The template author should also be able to explicitly define a help
string
 that is distinct and separate from the description of an individual
 parameter. An example where this use case originated was with Nova
 Keypairs. The description of a keypair parameter might be something
like,
 This is the name of a nova key pair that will be used to ssh to the
 compute instance. A help string for this same parameter would be, To
 learn more about nova keypairs click on this help article.

 I propose adding an additional field to the parameter definition:
  
  Parameters:
  parameter name:
  description: This is the name of a nova key pair that 
 will be used to
 ssh to the compute instance.
  help: To learn more about nova key pairs click on this 
 a
 href=/some/url/help article/a.
+1, this could be used today in the stack create screens of horizon.

 Use Case #3
 Grouping parameters would help the client make smarter decisions about
how
 to display the parameters for input to the end-user. This is so that all
 parameters related to some database resource can be intelligently
grouped
 together. In addition to grouping these parameters together, there
should
 be a method to ensuring that the order within the group of parameters
can
 be explicitly stated. This way, the client can return a group of
database
 parameters and the template author can indicate that the database
instance
 name should be first, then the username, then the password, instead of
 that group being returned in a random order.

  Parameters:
  db_name:
  group: db
  order: 0
  db_username:
  group: db
  order: 1
  db_password:
  group: db
  order: 2
  web_node_name:
  group: web_node
  order: 0
  keypair:
  group: web_node
  order: 1

 These are the use cases that have been clearly defined. The original
 purpose of the metadata section was to future-proof (I say
future-proof,
 you say pre-optimize ;) ) rapid iterations to potential client design.
The
 intent of the strategy was so that we did not overburden the Heat Core
 team with requirements that may fluctuate or change as we attempt to
 improve the user experience of Heat for the community. In hindsight I
can
 see how that intent was misconstrued and may have come off as
 condescending and I apologize for that.
We *need* a solution for grouping and ordering in horizon for generating
the parameter fields. All that is being done currently (I think) is
sorting by mandatory, then parameter name, which often pushes important
parameters to the bottom of the screen. I'd prefer explicit attributes
rather than inferring from a special parser that preserves the order of
parameters in the template. The parameter fields are built from the
results of a template-validate call.

Also, a group should really have its own order and description to
display, so we may need a new top-level section, eg
parameter-groups:
  db:
description: Database configuration options
order: 1
  web_node:
description: Web server configuration
order: 0
parameters:
  # as above

A 

Re: [openstack-dev] [heat][horizon]Heat UI related requirements roadmap

2013-11-26 Thread Tim Schnell

On Tue, Nov 26, 2013 at 4:35 PM, Tim Schnell 
tim.schn...@rackspace.commailto:tim.schn...@rackspace.com wrote:

From: Christopher Armstrong 
chris.armstr...@rackspace.commailto:chris.armstr...@rackspace.com

Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Tuesday, November 26, 2013 4:02 PM

To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [heat][horizon]Heat UI related requirements  
roadmap

On Tue, Nov 26, 2013 at 3:24 PM, Tim Schnell 
tim.schn...@rackspace.commailto:tim.schn...@rackspace.com wrote:
So the originally question that I attempted to pose was, Can we add a
schema-less metadata section to the template that can be used for a
variety of purposes?. It looks like the answer is no, we need to discuss
the features that would go in the metadata section and add them to the HOT
specification if they are viable. I don't necessarily agree with this
answer but I accept it as viable and take responsibility for the
long-winded process that it took to get to this point.

I think some valid points have been made and I have re-focused my efforts
into the following proposed solution.

I am fine with getting rid of the concept of a schema-less metadata
section. If we can arrive at a workable design for a few use cases then I
think that we won't need to discuss any of the options that Zane mentioned
for handling the metadata section, comments, separate file, or in the
template body.

Use Case #1
I see valid value in being able to group templates based on a type or
keyword. This would allow any client, Horizon or a Template Catalog
service, to better organize and handle display options for an end-user.

I believe that Ladislav initially proposed a solution that will work here.
So I will second a proposal that we add a new top-level field to the HOT
specification called keywords that contains this template type.

keywords: wordpress, mysql, etc



My immediate inclination would be to just make keywords/tags out-of-band 
metadata managed by the template repository. I imagine this would be something 
that would be very useful to change without having to edit the template anyway.

I'm not exactly sure what you are suggesting here, but I think that adding 
these keywords to the template will be less error prone than attempting to 
derive them some other way.


Basically, I'm just suggesting putting the tags outside of template. Not 
deriving them -- I still think they should be explicitly specified, but just 
putting them in e.g. the database instead of directly in the template.

Basically, in a public repository of templates, I can imagine tags being based 
on third-party or moderator input, instead of just based on what the template 
author says.  Keeping them outside of the template would allow content 
moderators to do that without posting a new version of the template.

Anyway, I don't feel that strongly about this - if there's a strong enough 
desire to see tags in the template, then I won't argue against it.
---

The primary reason I would like to see this live inside of the template is 
because these keywords should be tied to the current state of the template that 
is saved by Heat on Stack Create and Stack Update. If someone performs a Stack 
Update that changes the content of the template, they should be responsible for 
updating the keywords in the template. If the keywords live outside of the 
template, it will be difficult to keep them in sync with the actual content of 
the template.

I guess what I'm saying is that the keywords should follow the instantiation of 
the template which could morph into something that may not match the original 
keywords that may be saved into a database of templates somewhere.

Tim
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [heat][horizon]Heat UI related requirements roadmap

2013-11-26 Thread Angus Salkeld

On 26/11/13 22:55 +, Tim Schnell wrote:


On Tue, Nov 26, 2013 at 4:35 PM, Tim Schnell 
tim.schn...@rackspace.commailto:tim.schn...@rackspace.com wrote:

From: Christopher Armstrong 
chris.armstr...@rackspace.commailto:chris.armstr...@rackspace.com

Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Tuesday, November 26, 2013 4:02 PM

To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [heat][horizon]Heat UI related requirements  
roadmap

On Tue, Nov 26, 2013 at 3:24 PM, Tim Schnell 
tim.schn...@rackspace.commailto:tim.schn...@rackspace.com wrote:
So the originally question that I attempted to pose was, Can we add a
schema-less metadata section to the template that can be used for a
variety of purposes?. It looks like the answer is no, we need to discuss
the features that would go in the metadata section and add them to the HOT
specification if they are viable. I don't necessarily agree with this
answer but I accept it as viable and take responsibility for the
long-winded process that it took to get to this point.

I think some valid points have been made and I have re-focused my efforts
into the following proposed solution.

I am fine with getting rid of the concept of a schema-less metadata
section. If we can arrive at a workable design for a few use cases then I
think that we won't need to discuss any of the options that Zane mentioned
for handling the metadata section, comments, separate file, or in the
template body.

Use Case #1
I see valid value in being able to group templates based on a type or
keyword. This would allow any client, Horizon or a Template Catalog
service, to better organize and handle display options for an end-user.

I believe that Ladislav initially proposed a solution that will work here.
So I will second a proposal that we add a new top-level field to the HOT
specification called keywords that contains this template type.

   keywords: wordpress, mysql, etc



My immediate inclination would be to just make keywords/tags out-of-band 
metadata managed by the template repository. I imagine this would be something 
that would be very useful to change without having to edit the template anyway.

I'm not exactly sure what you are suggesting here, but I think that adding 
these keywords to the template will be less error prone than attempting to 
derive them some other way.


Basically, I'm just suggesting putting the tags outside of template. Not 
deriving them -- I still think they should be explicitly specified, but just 
putting them in e.g. the database instead of directly in the template.

Basically, in a public repository of templates, I can imagine tags being based 
on third-party or moderator input, instead of just based on what the template 
author says.  Keeping them outside of the template would allow content 
moderators to do that without posting a new version of the template.

Anyway, I don't feel that strongly about this - if there's a strong enough 
desire to see tags in the template, then I won't argue against it.
---

The primary reason I would like to see this live inside of the template is 
because these keywords should be tied to the current state of the template that 
is saved by Heat on Stack Create and Stack Update. If someone performs a Stack 
Update that changes the content of the template, they should be responsible for 
updating the keywords in the template. If the keywords live outside of the 
template, it will be difficult to keep them in sync with the actual content of 
the template.

I guess what I'm saying is that the keywords should follow the instantiation of 
the template which could morph into something that may not match the original 
keywords that may be saved into a database of templates somewhere.


You have moved into a different use case now:
I want a mechanism to tag particular versions of templates


I'd suggest your heat-template-tag does something like this:

hash=$(git hash-object template)
store_tag template $hash new tag name

then you can query if a template has a particular tag by hashing
the given template and looking the tags by hash.

So you could have a tag that is supported, that will be impossible
to fake. I don't see how you are going to do that by inserting
metadata into the template (a user could do that too).

-Angus



Tim



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [heat][horizon]Heat UI related requirements roadmap

2013-11-26 Thread Tim Schnell

On 11/26/13 5:24 PM, Angus Salkeld asalk...@redhat.com wrote:

On 26/11/13 22:55 +, Tim Schnell wrote:

On Tue, Nov 26, 2013 at 4:35 PM, Tim Schnell
tim.schn...@rackspace.commailto:tim.schn...@rackspace.com wrote:

From: Christopher Armstrong
chris.armstr...@rackspace.commailto:chris.armstr...@rackspace.com

Reply-To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.o
rg
Date: Tuesday, November 26, 2013 4:02 PM

To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.o
rg
Subject: Re: [openstack-dev] [heat][horizon]Heat UI related requirements
 roadmap

On Tue, Nov 26, 2013 at 3:24 PM, Tim Schnell
tim.schn...@rackspace.commailto:tim.schn...@rackspace.com wrote:
So the originally question that I attempted to pose was, Can we add a
schema-less metadata section to the template that can be used for a
variety of purposes?. It looks like the answer is no, we need to discuss
the features that would go in the metadata section and add them to the
HOT
specification if they are viable. I don't necessarily agree with this
answer but I accept it as viable and take responsibility for the
long-winded process that it took to get to this point.

I think some valid points have been made and I have re-focused my efforts
into the following proposed solution.

I am fine with getting rid of the concept of a schema-less metadata
section. If we can arrive at a workable design for a few use cases then I
think that we won't need to discuss any of the options that Zane
mentioned
for handling the metadata section, comments, separate file, or in the
template body.

Use Case #1
I see valid value in being able to group templates based on a type or
keyword. This would allow any client, Horizon or a Template Catalog
service, to better organize and handle display options for an end-user.

I believe that Ladislav initially proposed a solution that will work
here.
So I will second a proposal that we add a new top-level field to the HOT
specification called keywords that contains this template type.

keywords: wordpress, mysql, etc



My immediate inclination would be to just make keywords/tags out-of-band
metadata managed by the template repository. I imagine this would be
something that would be very useful to change without having to edit the
template anyway.

I'm not exactly sure what you are suggesting here, but I think that
adding these keywords to the template will be less error prone than
attempting to derive them some other way.


Basically, I'm just suggesting putting the tags outside of template. Not
deriving them -- I still think they should be explicitly specified, but
just putting them in e.g. the database instead of directly in the
template.

Basically, in a public repository of templates, I can imagine tags being
based on third-party or moderator input, instead of just based on what
the template author says.  Keeping them outside of the template would
allow content moderators to do that without posting a new version of the
template.

Anyway, I don't feel that strongly about this - if there's a strong
enough desire to see tags in the template, then I won't argue against it.
---

The primary reason I would like to see this live inside of the template
is because these keywords should be tied to the current state of the
template that is saved by Heat on Stack Create and Stack Update. If
someone performs a Stack Update that changes the content of the
template, they should be responsible for updating the keywords in the
template. If the keywords live outside of the template, it will be
difficult to keep them in sync with the actual content of the template.

I guess what I'm saying is that the keywords should follow the
instantiation of the template which could morph into something that may
not match the original keywords that may be saved into a database of
templates somewhere.

You have moved into a different use case now:
I want a mechanism to tag particular versions of templates


I'd suggest your heat-template-tag does something like this:

hash=$(git hash-object template)
store_tag template $hash new tag name

then you can query if a template has a particular tag by hashing
the given template and looking the tags by hash.

So you could have a tag that is supported, that will be impossible
to fake. I don't see how you are going to do that by inserting
metadata into the template (a user could do that too).

-Angus

That is not the use case that I'm attempting to make, let me try again.
For what it's worth I agree, that in this use case I want a mechanism to
tag particular versions of templates your solution makes sense and will
probably be necessary as the requirements for the template catalog start
to become defined.

What I am attempting to explain is actually much simpler than that. There
are 2 times in a UI that I would be interested in the keywords

Re: [openstack-dev] [heat][horizon]Heat UI related requirements roadmap

2013-11-26 Thread Clint Byrum
Excerpts from Tim Schnell's message of 2013-11-26 13:24:22 -0800:
 So the originally question that I attempted to pose was, Can we add a
 schema-less metadata section to the template that can be used for a
 variety of purposes?. It looks like the answer is no, we need to discuss
 the features that would go in the metadata section and add them to the HOT
 specification if they are viable. I don't necessarily agree with this
 answer but I accept it as viable and take responsibility for the
 long-winded process that it took to get to this point.
 
 I think some valid points have been made and I have re-focused my efforts
 into the following proposed solution.
 
 I am fine with getting rid of the concept of a schema-less metadata
 section. If we can arrive at a workable design for a few use cases then I
 think that we won't need to discuss any of the options that Zane mentioned
 for handling the metadata section, comments, separate file, or in the
 template body.
 
 Use Case #1
 I see valid value in being able to group templates based on a type or
 keyword. This would allow any client, Horizon or a Template Catalog
 service, to better organize and handle display options for an end-user.
 
 I believe that Ladislav initially proposed a solution that will work here.
 So I will second a proposal that we add a new top-level field to the HOT
 specification called keywords that contains this template type.
 
 keywords: wordpress, mysql, etcŠ
 

What is the use case here. For me, a use case needs to be specific to
be useful at helping to guide more generic feature design. What I see
above is a generic feature specification with no actual concrete need
for it. These keywords should be in the template description, which
should be full-text searchable anyway. Group templates based on a type
or keyword. could mean a lot of things to a lot of different classes
of Heat users.

 
 Use Case #2
 The template author should also be able to explicitly define a help string
 that is distinct and separate from the description of an individual
 parameter. An example where this use case originated was with Nova
 Keypairs. The description of a keypair parameter might be something like,
 This is the name of a nova key pair that will be used to ssh to the
 compute instance. A help string for this same parameter would be, To
 learn more about nova keypairs click on this help article.
 
 I propose adding an additional field to the parameter definition:
 
 Parameters:
 parameter name:
 description: This is the name of a nova key pair that will be 
 used to
 ssh to the compute instance.
 help: To learn more about nova key pairs click on this a
 href=/some/url/help article/a.


+1. A help string per parameter is a fantastic idea. Sounds like a nice
analog to doc-strings.

 Use Case #3
 Grouping parameters would help the client make smarter decisions about how
 to display the parameters for input to the end-user. This is so that all
 parameters related to some database resource can be intelligently grouped
 together. In addition to grouping these parameters together, there should
 be a method to ensuring that the order within the group of parameters can
 be explicitly stated. This way, the client can return a group of database
 parameters and the template author can indicate that the database instance
 name should be first, then the username, then the password, instead of
 that group being returned in a random order.
 
 Parameters:
 db_name:
 group: db
 order: 0
 db_username:
 group: db
 order: 1
 db_password:
 group: db
 order: 2
 web_node_name:
 group: web_node
 order: 0
 keypair:
 group: web_node
 order: 1


+1 for grouping. Your use case is perfectly specified above. Love it.

However, your format feels very forced. Integers for ordering? We have
lists for that.

How about this:

parameters:
  db:
type: group
parameters:
  - db_name
  - db_username
  - db_password
  web_node:
type: group
parameters:
  - web_node_name
  - keypair
  db_name:
type: string
  ...


This way we are just providing the groupings outside of the parameters
themselves. Using a list means the order is as it appears here.

Another option is to allow specifying whole parameters in-line there,
like

parameters:
  db:
type: group
parameters:
  - db_name:
type: string

But that opens up a can of worms that we can leave closed for now and
just do the above.

 These are the use cases that have been clearly defined. The original
 purpose of the metadata section was to future-proof (I say future-proof,
 you say pre-optimize ;) ) rapid iterations to potential client design. The
 intent of the strategy was so that we did not overburden the Heat Core
 team with requirements that may fluctuate or change as we attempt 

Re: [openstack-dev] [heat][horizon]Heat UI related requirements roadmap

2013-11-26 Thread Clint Byrum
Excerpts from Ladislav Smola's message of 2013-11-26 06:04:12 -0800:
 Hello,
 
 seems too big to do the inline comments, so just a few notes here:
 
 If we truly want to have Templates portable, it would mean to have the 
 'metadata' somehow standardised, right?

Can you point to another portable application distribution system where
meta-data about the applications has been standardized in the language
itself? Can you give us data on how successful that is?

I can point to plenty where the meta-data is specified outside the
application itself, because it makes sense that these are two different
concerns.

 Otherwise if every UI will add their own metadata, then I hardly see the 
 templates as portable. I think first step would be then to delete
 the metadata and add your own, unless you are fine to have 80% of the 
 template some metadata you don't use. That also won't
 help the readability. What will help a readability are the verbose comments.


Actually that is just the thing. Keeping them portable means making them
useful in different deployments without changing them. Deployments are
not all going to want to organize things by the same set of tags.

Consider a private cloud used for deploying IT apps internally. They may
want to tag SugarCRM as 'sales' and OpenERP as 'manufacturing'. These
are separate concerns, so they should not be in the same template.

What _would_ be useful would be curation of those packaged Heat apps
into a generally useful default repository for Heat deployers to take
advantage of. A pypi for Heat, if you will. That would help to
homogenize things and prevent wasteful forking of the most generic
templates. But the decisions of those curators should not be set in
stone for all deployers.

 I am not really sure how long it can take to add new specialized tags, 
 that are used only in Horizon and are well documented. I think showing
 this, should get the patch merged very quickly. That seems to me like a 
 portable solution.
 
 IMO for the template catalogue we would probably need a new service, 
 something like Glance, so that's probably a more distant future.


Why not just use glance? Where is this belief coming from that Glance
would be hard to add what is basically a single image type to? I
understand SOA and we need to separate things. But registry of blobs
of data has a service.

If people want to expose a user-uploadable HOT glance but not
a user-uploadable image glance, then have two endpoints, and two
glances. But don't write a whole new piece of software just because
modifying an existing one seems hard.

 For the use-cases:
 ---
 
 ad 1)
 Something more general next to Description may be more useful, like 
 keywords, packages or components.
 Example:
 
 Description...
 Keywords: wordpress, mysql...
 
 Or you could parse it from e.g. packages (though that is not always 
 used, so being able to write it explicitly might be handy)


If you take out the catalog though, this has no place in the template.

 ad 2)
 Maybe adding something like 'author' tag may be a good idea, though you 
 can find all the history in git repo,
 given you use https://github.com/openstack/heat-templates . If you have 
 different repo, adding something like
 Origin: https://github.com/openstack/heat-templates maybe?
 

Both of those things work great if you make git repo+meta-data file the
packaging format.

Things like Origin: get out of date really fast in my experience because
they are informational and not actually important to the use of the
package/code/etc.

 ad 3)
 So having a fix and documented schema seems to be a good way to be 
 portable, at least to me. I am not
 against UI only tags inside the template, that are really useful for 
 everybody. We will find out by collectively
 reviewing that, which usually brings some easier solution.
 

UI only tags are awesome, and I like them a lot.

 Or you don't think, it will get too wild to have some 'metadata' section 
 completely ignored by Heat? Seems
 to me like there will be a lot of cases, when people won't push their 
 template to upstream, because of the
 metadata they have added to their templates, that nobody else will ever 
 use. Is somebody else concerned
 about this?

I actually think such a section will be abused heavily to have different
templates per deployment. Keeping this stuff out of the template means
deployers who need to arrange things differently can consume the
template without modifying it.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [heat][horizon]Heat UI related requirements roadmap

2013-11-25 Thread Tim Schnell
Hi Steve,

As one of the UI developers driving the requirements behind these new
blueprints I wanted to take a moment to assure you and the rest of the
Openstack community that the primary purpose of pushing these requirements
out to the community is to help improve the User Experience for Heat for
everyone. Every major UI feature that I have implemented for Heat has been
included in Horizon, see the Heat Topology, and these requirements should
improve the value of Heat, regardless of the UI.


Stack/template metadata
We have a fundamental need to have the ability to reference some
additional metadata about a template that Heat does not care about. There
are many possible use cases for this need but the primary point is that we
need a place in the template where we can iterate on the schema of the
metadata without going through a lengthy design review. As far as I know,
we are the only team attempting to actually productize Heat at the moment
and this means that we are encountering requirements and requests that do
not affect Heat directly but simply require Heat to allow a little wiggle
room to flesh out a great user experience.

There is precedence for an optional metadata section that can contain any
end-user data in other Openstack projects and it is necessary in order to
iterate quickly and provide value to Heat.

There are many use cases that can be discussed here, but I wanted to
reiterate an initial discussion point that, by definition,
stack/template_metadata does not have any hard requirements in terms of
schema or what does or does not belong in it.

One of the initial use cases is to allow template authors to categorize
the template as a specific type.

template_metadata:
short_description: Wordpress


This would let the client of the Heat API group the templates by type
which would create a better user experience when selecting or managing
templates. The the end-user could select Wordpress and drill down
further to select templates with different options, single node, 2 web
nodes, etc...

Once a feature has consistently proven that it adds value to Heat or
Horizon, then I would suggest that we can discuss the schema for that
feature and codify it then.

In order to keep the discussion simple, I am only responding to the need
for stack/template metadata at the moment but I'm sure discussions on the
management api and template catalog will follow.

Thanks,
Tim
@tims on irc






On 11/25/13 12:39 PM, Steven Hardy sha...@redhat.com wrote:

All,

So, lately we've been seeing more patches posted proposing added
functionality to Heat (the API and template syntax) related to
development of UI functionality.

This makes me both happy (because folks want to use Heat!) and sad
(because
it's evident there are several proprietary UI's being developed, rather
than collaboration focussed on making Horizon Heat functionality great)

One of the most contentious ones currently is that proposing adding
metadata to the HOT template specification, designed to contain data which
Heat does not use - my understanding is the primary use-case for this is
some UI for managing applictions via Heat:

https://review.openstack.org/#/c/56450/

I'd like to attempt to break down some of the communication barriers which
are increasingly apparent, and refocus our attention on what the actual
requirements are, and how they relate to improving Heat support in
Horizon.

The list of things being proposed I can think of are (I'm sure there are
more):
- Stack/template metadata
- Template repository/versioning
- Management-API functionality (for a Heat service administrator)
- Exposing build information

I think the template repository and template metadata items are closely
related - if we can figure out how we expect users to interact with
multiple versions of templates, access public template repositories,
attach
metadata/notes to their template etc in Horizon, then I think much of the
requirement driving those patches can be satisfied (without necessarily
implementing that functionality or storing that data in Heat).

For those who've already posted patches and got negative feedback, here's
my plea - please, please, start communicating the requirements and
use-cases, then we can discuss the solution together.  Just posting a
solution with no prior discussion and a minimal blueprint is a really slow
way to get your required functionality into Heat, and it's frustrating for
everyone :(

So, lets have a Heat-UI-requirements amnesty, what UI related
functionality
do you want in Heat, and why (requirements, use-case/user-story)

Hopefully if we can get these requirements out in the open, it will help
formulate a roadmap for future improvement of Heat support in Horizon.

Obviously non-Horizon UI users of Heat also directly benefit from this,
but
IMO we must focus the discussion primarily on what makes sense for
Horizon,
not what makes sense for $veiled_reference_to_internal_project, as the
wider community don't 

Re: [openstack-dev] [heat][horizon]Heat UI related requirements roadmap

2013-11-25 Thread Clint Byrum
Excerpts from Tim Schnell's message of 2013-11-25 14:51:39 -0800:
 Hi Steve,
 
 As one of the UI developers driving the requirements behind these new
 blueprints I wanted to take a moment to assure you and the rest of the
 Openstack community that the primary purpose of pushing these requirements
 out to the community is to help improve the User Experience for Heat for
 everyone. Every major UI feature that I have implemented for Heat has been
 included in Horizon, see the Heat Topology, and these requirements should
 improve the value of Heat, regardless of the UI.
 
 
 Stack/template metadata
 We have a fundamental need to have the ability to reference some
 additional metadata about a template that Heat does not care about. There
 are many possible use cases for this need but the primary point is that we
 need a place in the template where we can iterate on the schema of the
 metadata without going through a lengthy design review. As far as I know,
 we are the only team attempting to actually productize Heat at the moment
 and this means that we are encountering requirements and requests that do
 not affect Heat directly but simply require Heat to allow a little wiggle
 room to flesh out a great user experience.
 

Wiggle room is indeed provided. But reviewers need to understand your
motivations, which is usually what blueprints are used for. If you're
getting push back, it is likely because your blueprints to not make the
use cases and long term vision obvious.

 There is precedence for an optional metadata section that can contain any
 end-user data in other Openstack projects and it is necessary in order to
 iterate quickly and provide value to Heat.
 

Nobody has said you can't have meta-data on stacks, which is what other
projects use.

 There are many use cases that can be discussed here, but I wanted to
 reiterate an initial discussion point that, by definition,
 stack/template_metadata does not have any hard requirements in terms of
 schema or what does or does not belong in it.
 
 One of the initial use cases is to allow template authors to categorize
 the template as a specific type.
 
 template_metadata:
 short_description: Wordpress
 
 

Interesting. Would you support adding a category keyword to python so
we don't have to put it in setup.cfg and so that the egg format doesn't
need that section? Pypi can just parse the python to categorize the apps
when they're uploaded. We could also have a file on disk for qcow2 images
that we upload to glance that will define the meta-data.

To be more direct, I don't think the templates themselves are where this
meta-data belongs. A template is self-aware by definition, it doesn't
need the global metadata section to tell it that it is WordPress. For
anything else that needs to be globally referenced there are parameters.
Having less defined inside the template means that you get _more_ wiggle
room for your template repository.

I 100% support having a template catalog. IMO it should be glance,
which is our catalog service in OpenStack. Who cares if nova or heat are
consuming images or templates. It is just sharable blobs of data and
meta-data in a highly scalable service. It already has the concept of
global and tenant-scope. It just needs an image type of 'hot' and then
heat can start consuming templates from glance. And the template authors
should maintain some packaging meta-data in glance to communicate to
users that this is Wordpress and Single-Node. If Glance's meta-data
is too limiting, expand it! I'm sure image authors and consumers would
appreciate that.

 This would let the client of the Heat API group the templates by type
 which would create a better user experience when selecting or managing
 templates. The the end-user could select Wordpress and drill down
 further to select templates with different options, single node, 2 web
 nodes, etc...
 

That is all api stuff, not language stuff.

 Once a feature has consistently proven that it adds value to Heat or
 Horizon, then I would suggest that we can discuss the schema for that
 feature and codify it then.
 
 In order to keep the discussion simple, I am only responding to the need
 for stack/template metadata at the moment but I'm sure discussions on the
 management api and template catalog will follow.
 

Your example puts the template catalog in front of this feature, and I
think that exposes this feature as misguided.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [heat][horizon]Heat UI related requirements roadmap

2013-11-25 Thread Fox, Kevin M
I agree that maybe an external file might be better suited to extra metadata. 
I've found it rare that you ever use just one template per stack. Usually it is 
a set of nested templates. This would allow for advanced ui features like an 
icon for the stack.

On the other hand, there is the template top level Description field, which 
I'm not sure is used by heat other then to tell something useful to the User 
UI. So, putting some metadata about the template in the template itself does 
not seem unprecedented.

Thanks,
Kevin

From: Clint Byrum [cl...@fewbar.com]
Sent: Monday, November 25, 2013 3:46 PM
To: openstack-dev
Subject: Re: [openstack-dev] [heat][horizon]Heat UI related requirements   
roadmap

Excerpts from Tim Schnell's message of 2013-11-25 14:51:39 -0800:
 Hi Steve,

 As one of the UI developers driving the requirements behind these new
 blueprints I wanted to take a moment to assure you and the rest of the
 Openstack community that the primary purpose of pushing these requirements
 out to the community is to help improve the User Experience for Heat for
 everyone. Every major UI feature that I have implemented for Heat has been
 included in Horizon, see the Heat Topology, and these requirements should
 improve the value of Heat, regardless of the UI.


 Stack/template metadata
 We have a fundamental need to have the ability to reference some
 additional metadata about a template that Heat does not care about. There
 are many possible use cases for this need but the primary point is that we
 need a place in the template where we can iterate on the schema of the
 metadata without going through a lengthy design review. As far as I know,
 we are the only team attempting to actually productize Heat at the moment
 and this means that we are encountering requirements and requests that do
 not affect Heat directly but simply require Heat to allow a little wiggle
 room to flesh out a great user experience.


Wiggle room is indeed provided. But reviewers need to understand your
motivations, which is usually what blueprints are used for. If you're
getting push back, it is likely because your blueprints to not make the
use cases and long term vision obvious.

 There is precedence for an optional metadata section that can contain any
 end-user data in other Openstack projects and it is necessary in order to
 iterate quickly and provide value to Heat.


Nobody has said you can't have meta-data on stacks, which is what other
projects use.

 There are many use cases that can be discussed here, but I wanted to
 reiterate an initial discussion point that, by definition,
 stack/template_metadata does not have any hard requirements in terms of
 schema or what does or does not belong in it.

 One of the initial use cases is to allow template authors to categorize
 the template as a specific type.

 template_metadata:
 short_description: Wordpress



Interesting. Would you support adding a category keyword to python so
we don't have to put it in setup.cfg and so that the egg format doesn't
need that section? Pypi can just parse the python to categorize the apps
when they're uploaded. We could also have a file on disk for qcow2 images
that we upload to glance that will define the meta-data.

To be more direct, I don't think the templates themselves are where this
meta-data belongs. A template is self-aware by definition, it doesn't
need the global metadata section to tell it that it is WordPress. For
anything else that needs to be globally referenced there are parameters.
Having less defined inside the template means that you get _more_ wiggle
room for your template repository.

I 100% support having a template catalog. IMO it should be glance,
which is our catalog service in OpenStack. Who cares if nova or heat are
consuming images or templates. It is just sharable blobs of data and
meta-data in a highly scalable service. It already has the concept of
global and tenant-scope. It just needs an image type of 'hot' and then
heat can start consuming templates from glance. And the template authors
should maintain some packaging meta-data in glance to communicate to
users that this is Wordpress and Single-Node. If Glance's meta-data
is too limiting, expand it! I'm sure image authors and consumers would
appreciate that.

 This would let the client of the Heat API group the templates by type
 which would create a better user experience when selecting or managing
 templates. The the end-user could select Wordpress and drill down
 further to select templates with different options, single node, 2 web
 nodes, etc...


That is all api stuff, not language stuff.

 Once a feature has consistently proven that it adds value to Heat or
 Horizon, then I would suggest that we can discuss the schema for that
 feature and codify it then.

 In order to keep the discussion simple, I am only responding to the need
 for stack/template metadata at the moment but I'm sure discussions

Re: [openstack-dev] [heat][horizon]Heat UI related requirements roadmap

2013-11-25 Thread Keith Bray


On 11/25/13 5:46 PM, Clint Byrum cl...@fewbar.com wrote:

Excerpts from Tim Schnell's message of 2013-11-25 14:51:39 -0800:
 Hi Steve,
 
 As one of the UI developers driving the requirements behind these new
 blueprints I wanted to take a moment to assure you and the rest of the
 Openstack community that the primary purpose of pushing these
requirements
 out to the community is to help improve the User Experience for Heat for
 everyone. Every major UI feature that I have implemented for Heat has
been
 included in Horizon, see the Heat Topology, and these requirements
should
 improve the value of Heat, regardless of the UI.
 
 
 Stack/template metadata
 We have a fundamental need to have the ability to reference some
 additional metadata about a template that Heat does not care about.
There
 are many possible use cases for this need but the primary point is that
we
 need a place in the template where we can iterate on the schema of the
 metadata without going through a lengthy design review. As far as I
know,
 we are the only team attempting to actually productize Heat at the
moment
 and this means that we are encountering requirements and requests that
do
 not affect Heat directly but simply require Heat to allow a little
wiggle
 room to flesh out a great user experience.
 

Wiggle room is indeed provided. But reviewers need to understand your
motivations, which is usually what blueprints are used for. If you're
getting push back, it is likely because your blueprints to not make the
use cases and long term vision obvious.

Clint, can you be more specific on what is not clear about the use case?
What I am seeing is that the use case of meta data is not what is being
contested, but that the Blueprint of where meta data should go is being
contested by only a few (but not all) of the core devs.  The Blueprint for
in-template metadata was already approved for Icehouse, but now that work
has been delivered on the implementation of that blueprint, the blueprint
itself is being contested:
   https://blueprints.launchpad.net/heat/+spec/namespace-stack-metadata
I'd like to propose that the blueprint that has been accepted go forth
with the code that exactly implements it, and if there are alternative
proposals and appropriate reasons for the community to come to consensus
on a different approach, that we then iterate and move the data (deprecate
the older feature if necessary, e.g. If that decision comes after
Icehouse, else of a different/better implementation comes before Icehouse,
then no harm done).



 There is precedence for an optional metadata section that can contain
any
 end-user data in other Openstack projects and it is necessary in order
to
 iterate quickly and provide value to Heat.
 

Nobody has said you can't have meta-data on stacks, which is what other
projects use.

 There are many use cases that can be discussed here, but I wanted to
 reiterate an initial discussion point that, by definition,
 stack/template_metadata does not have any hard requirements in terms
of
 schema or what does or does not belong in it.
 
 One of the initial use cases is to allow template authors to categorize
 the template as a specific type.
 
 template_metadata:
 short_description: Wordpress
 
 

Interesting. Would you support adding a category keyword to python so
we don't have to put it in setup.cfg and so that the egg format doesn't
need that section? Pypi can just parse the python to categorize the apps
when they're uploaded. We could also have a file on disk for qcow2 images
that we upload to glance that will define the meta-data.

To be more direct, I don't think the templates themselves are where this
meta-data belongs. A template is self-aware by definition, it doesn't
need the global metadata section to tell it that it is WordPress. For
anything else that needs to be globally referenced there are parameters.
Having less defined inside the template means that you get _more_ wiggle
room for your template repository.

Clint, you are correct that the Template does not need to know what it is.
 It's every other service (and users of those services) that a Template
passes through or to that would care to know what it is. We are suggesting
we put that meta data in the template file and expressly ignore it for
purposes of parsing the template language in the Heat engine, so we agree
it not a necessary part of the template.  Sure, we could encode the
metadata info in a separate catalog...  but, take the template out of the
catalog and now all that useful associated data is lost or would need to
be recreated by someone or some service.  That does not make the template
portable, and that is a key aspect of what we are trying to achieve (all
user-facing clients, like Horizon, or humans reading the file, can take
advantage). We don't entirely know yet what is most useful in portability
and what isn't, so meta data in-template provides the wiggle room
innovation space to suss that out.  We already know of 

Re: [openstack-dev] [heat][horizon]Heat UI related requirements roadmap

2013-11-25 Thread Steve Baker
On 11/26/2013 03:26 PM, Keith Bray wrote:

 On 11/25/13 5:46 PM, Clint Byrum cl...@fewbar.com wrote:

 Excerpts from Tim Schnell's message of 2013-11-25 14:51:39 -0800:
 Hi Steve,

 As one of the UI developers driving the requirements behind these new
 blueprints I wanted to take a moment to assure you and the rest of the
 Openstack community that the primary purpose of pushing these
 requirements
 out to the community is to help improve the User Experience for Heat for
 everyone. Every major UI feature that I have implemented for Heat has
 been
 included in Horizon, see the Heat Topology, and these requirements
 should
 improve the value of Heat, regardless of the UI.


 Stack/template metadata
 We have a fundamental need to have the ability to reference some
 additional metadata about a template that Heat does not care about.
 There
 are many possible use cases for this need but the primary point is that
 we
 need a place in the template where we can iterate on the schema of the
 metadata without going through a lengthy design review. As far as I
 know,
 we are the only team attempting to actually productize Heat at the
 moment
 and this means that we are encountering requirements and requests that
 do
 not affect Heat directly but simply require Heat to allow a little
 wiggle
 room to flesh out a great user experience.

 Wiggle room is indeed provided. But reviewers need to understand your
 motivations, which is usually what blueprints are used for. If you're
 getting push back, it is likely because your blueprints to not make the
 use cases and long term vision obvious.
 Clint, can you be more specific on what is not clear about the use case?
 What I am seeing is that the use case of meta data is not what is being
 contested, but that the Blueprint of where meta data should go is being
 contested by only a few (but not all) of the core devs.  The Blueprint for
 in-template metadata was already approved for Icehouse, but now that work
 has been delivered on the implementation of that blueprint, the blueprint
 itself is being contested:
https://blueprints.launchpad.net/heat/+spec/namespace-stack-metadata
 I'd like to propose that the blueprint that has been accepted go forth
 with the code that exactly implements it, and if there are alternative
 proposals and appropriate reasons for the community to come to consensus
 on a different approach, that we then iterate and move the data (deprecate
 the older feature if necessary, e.g. If that decision comes after
 Icehouse, else of a different/better implementation comes before Icehouse,
 then no harm done).
I don't think the Heat project has ever set any expectations over what
it means for a blueprint to be Approved. Given that the PTL can approve
blueprints (that's me =) but anyone in heat-core can legitimately -2 any
review, I don't think it is realistic to expect Approved to mean
anything other than something that is worthy of starting to work on.
Nova has adopted a policy of only approving blueprints will full
specifications. That would avoid situations like this but I'd like to
avoid that until Heat is more mature and that kind of process is really
necessary.

How a blueprint is progressed after approval depends entirely on the
feature and the people involved. This could be one of:
1) Implement it already, its trivial!
2) Write enough of a specification to convince enough core developers
that it has value
3) Have list, irc and summit discussions for some amount of time, then
do 2) or 1)

In this case 1) has proven to be not enough, so I would recommend 2). I
don't think this will come to 3) but we seem to be well on the way ;)

I've linked this blank wiki page to the blueprint so a spec containing
use cases can go there.

 There is precedence for an optional metadata section that can contain
 any
 end-user data in other Openstack projects and it is necessary in order
 to
 iterate quickly and provide value to Heat.

 Nobody has said you can't have meta-data on stacks, which is what other
 projects use.

 There are many use cases that can be discussed here, but I wanted to
 reiterate an initial discussion point that, by definition,
 stack/template_metadata does not have any hard requirements in terms
 of
 schema or what does or does not belong in it.

 One of the initial use cases is to allow template authors to categorize
 the template as a specific type.

 template_metadata:
 short_description: Wordpress

 
 Interesting. Would you support adding a category keyword to python so
 we don't have to put it in setup.cfg and so that the egg format doesn't
 need that section? Pypi can just parse the python to categorize the apps
 when they're uploaded. We could also have a file on disk for qcow2 images
 that we upload to glance that will define the meta-data.

 To be more direct, I don't think the templates themselves are where this
 meta-data belongs. A template is self-aware by definition, it doesn't
 need the global metadata section to 

Re: [openstack-dev] [heat][horizon]Heat UI related requirements roadmap

2013-11-25 Thread Keith Bray
Thanks Steve.  I appreciate your input. I have added the use cases for all to 
review:
https://wiki.openstack.org/wiki/Heat/StackMetadata

What are next steps to drive this to resolution?

Kind regards,
-Keith

From: Steve Baker sba...@redhat.commailto:sba...@redhat.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Monday, November 25, 2013 11:47 PM
To: 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [heat][horizon]Heat UI related requirements  
roadmap

On 11/26/2013 03:26 PM, Keith Bray wrote:

On 11/25/13 5:46 PM, Clint Byrum cl...@fewbar.commailto:cl...@fewbar.com 
wrote:



Excerpts from Tim Schnell's message of 2013-11-25 14:51:39 -0800:


Hi Steve,

As one of the UI developers driving the requirements behind these new
blueprints I wanted to take a moment to assure you and the rest of the
Openstack community that the primary purpose of pushing these
requirements
out to the community is to help improve the User Experience for Heat for
everyone. Every major UI feature that I have implemented for Heat has
been
included in Horizon, see the Heat Topology, and these requirements
should
improve the value of Heat, regardless of the UI.


Stack/template metadata
We have a fundamental need to have the ability to reference some
additional metadata about a template that Heat does not care about.
There
are many possible use cases for this need but the primary point is that
we
need a place in the template where we can iterate on the schema of the
metadata without going through a lengthy design review. As far as I
know,
we are the only team attempting to actually productize Heat at the
moment
and this means that we are encountering requirements and requests that
do
not affect Heat directly but simply require Heat to allow a little
wiggle
room to flesh out a great user experience.



Wiggle room is indeed provided. But reviewers need to understand your
motivations, which is usually what blueprints are used for. If you're
getting push back, it is likely because your blueprints to not make the
use cases and long term vision obvious.


Clint, can you be more specific on what is not clear about the use case?
What I am seeing is that the use case of meta data is not what is being
contested, but that the Blueprint of where meta data should go is being
contested by only a few (but not all) of the core devs.  The Blueprint for
in-template metadata was already approved for Icehouse, but now that work
has been delivered on the implementation of that blueprint, the blueprint
itself is being contested:
   https://blueprints.launchpad.net/heat/+spec/namespace-stack-metadata
I'd like to propose that the blueprint that has been accepted go forth
with the code that exactly implements it, and if there are alternative
proposals and appropriate reasons for the community to come to consensus
on a different approach, that we then iterate and move the data (deprecate
the older feature if necessary, e.g. If that decision comes after
Icehouse, else of a different/better implementation comes before Icehouse,
then no harm done).


I don't think the Heat project has ever set any expectations over what it means 
for a blueprint to be Approved. Given that the PTL can approve blueprints 
(that's me =) but anyone in heat-core can legitimately -2 any review, I don't 
think it is realistic to expect Approved to mean anything other than something 
that is worthy of starting to work on. Nova has adopted a policy of only 
approving blueprints will full specifications. That would avoid situations like 
this but I'd like to avoid that until Heat is more mature and that kind of 
process is really necessary.

How a blueprint is progressed after approval depends entirely on the feature 
and the people involved. This could be one of:
1) Implement it already, its trivial!
2) Write enough of a specification to convince enough core developers that it 
has value
3) Have list, irc and summit discussions for some amount of time, then do 2) or 
1)

In this case 1) has proven to be not enough, so I would recommend 2). I don't 
think this will come to 3) but we seem to be well on the way ;)

I've linked this blank wiki page to the blueprint so a spec containing use 
cases can go there.

There is precedence for an optional metadata section that can contain
any
end-user data in other Openstack projects and it is necessary in order
to
iterate quickly and provide value to Heat.



Nobody has said you can't have meta-data on stacks, which is what other
projects use.



There are many use cases that can be discussed here, but I wanted to
reiterate an initial discussion point that, by definition,
stack/template_metadata does not have any hard requirements in terms
of
schema or what does or does not belong in it.

One of the initial use