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


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


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

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


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

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

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

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


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


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


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

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

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

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


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


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

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

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

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


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

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