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

[Tim Schnell]

Hi Steve,

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


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

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

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

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

template_metadata:
short_description: Wordpress


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

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

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

Thanks,
Tim
@tims on irc






On 11/25/13 12:39 PM, "Steven Hardy"  wrote:

>All,
>
>So, lately we've been seeing more patches posted proposing added
>functionality to Heat (the API and template syntax) related to
>development of UI functionality.
>
>This makes me both happy (because folks want to use Heat!) and sad
>(because
>it's evident there are several proprietary UI's being developed, rather
>than collaboration focussed on making Horizon Heat functionality great)
>
>One of the most contentious ones currently is that proposing adding
>metadata to the HOT template specification, designed to contain data which
>Heat does not use - my understanding is the primary use-case for this is
>some UI for managing applictions via Heat:
>
>https://review.openstack.org/#/c/56450/
>
>I'd like to attempt to break down some of the communication barriers which
>are increasingly apparent, and refocus our attention on what the actual
>requirements are, and how they relate to improving Heat support in
>Horizon.
>
>The list of things being proposed I can think of are (I'm sure there are
>more):
>- Stack/template metadata
>- Template repository/versioning
>- Management-API functionality (for a Heat service administrator)
>- Exposing build information
>
>I think the template repository and template metadata items are closely
>related - if we can figure out how we expect users to interact with
>multiple versions of templates, access public template repositories,
>attach
>metadata/notes to their template etc in Horizon, then I think much of the
>requirement driving those patches can be satisfied (without necessarily
>implementing that functionality or storing that data in Heat).
>
>For those who've already posted patches and got negative feedback, here's
>my plea - please, please, start communicating the requirements and
>use-cases, then we can discuss the solution together.  Just posting a
>solution with no prior discussion and a minimal blueprint is a really slow
>way to get your required functionality into Heat, and it's frustrating for
>everyone :(
>
>So, lets have a Heat-UI-requirements amnesty, what UI related
>functionality
>do you want in Heat, and why (requirements, use-case/user-story)
>
>Hopefully if we can get these requirements out in the open, it will help
>formulate a roadmap for future improvement of Heat support in Horizon.
>
>Obviously non-Horizon UI users of Heat also directly benefit from this,
>but
>IMO we must focus the discussion primarily on what makes sense for
>Horizon,
>not what makes sense for $veiled_referenc

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

[Tim Schnell]

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

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

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

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

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

keywords: wordpress, mysql, etcŠ


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

I propose adding an additional field to the parameter definition:

Parameters:
:
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 
help article.

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, "Zane Bitter"  wrote:

>

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

[Tim Schnell]

From: Christopher Armstrong 
mailto:chris.armstr...@rackspace.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, November 26, 2013 4:02 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto: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 
mailto: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.


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:
:
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 
help article.


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.


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:

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

[Tim Schnell]

From: Steve Baker mailto:sba...@redhat.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, November 26, 2013 4:29 PM
To: 
"openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>" 
mailto: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 
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.


+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

[Tim Schnell]

On 11/26/13 4:16 PM, "Steve Baker"  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:
>>  :
>>  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 
>> > href="/some/url/">help article.
>+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

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

[Tim Schnell]

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

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

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

To: "OpenStack Development Mailing List (not for usage questions)" 
mailto: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 
mailto: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

[Tim Schnell]

On 11/26/13 5:24 PM, "Angus Salkeld"  wrote:

>On 26/11/13 22:55 +, Tim Schnell wrote:
>>
>>On Tue, Nov 26, 2013 at 4:35 PM, Tim Schnell
>>mailto:tim.schn...@rackspace.com>> wrote:
>>
>>From: Christopher Armstrong
>>mailto:chris.armstr...@rackspace.com>>
>>
>>Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>>mailto:openstack-dev@lists.openstack.o
>>rg>>
>>Date: Tuesday, November 26, 2013 4:02 PM
>>
>>To: "OpenStack Development Mailing List (not for usage questions)"
>>mailto:openstack-dev@lists.openstack.o
>>rg>>
>>Subject: Re: [openstack-dev] [heat][horizon]Heat UI related requirements
>>& roadmap
>>
>>On Tue, Nov 26, 2013 at 3:24 PM, Tim Schnell
>>mailto: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 )
>store_tag  $hash 
>
>then you can query if

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

[Tim Schnell]

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


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

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

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

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

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

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

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

Thanks,
Tim

On 11/27/13 3:19 AM, "Thomas Spatzier"  wrote:

>Excerpts from Tim Schnell's message on 27.11.2013 00:44:04:
>> From: Tim Schnell 
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> ,
>> Date: 27.11.2013 00:47
>> Subject: Re: [openstack-dev] [heat][horizon]Heat UI related
>> requirements & roadmap
>>
>>
>
>
>
>> 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 

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

[Tim Schnell]

On 11/27/13 10:39 AM, "Zane Bitter"  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

[Tim Schnell]

On 11/27/13 10: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?)

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

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

[Tim Schnell]

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

Tim Schnell
Software Developer
Rackspace





On 11/27/13 10:53 AM, "Thomas Spatzier"  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  wrote on 27.11.2013 16:24:18:
>> From: Tim Schnell 
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> ,
>> 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" 
>wrote:
>>
>> >Excerpts from Tim Schnell's message on 27.11.2013 00:44:04:
>> >> From: Tim Schnell 
>> >> To: "OpenStack Development Mailing List (not for usage questions)"
>> >> ,
>> >> Date: 27.11.2013 00:47
>> >> Subject: Re: [openstack-dev] [heat][horizon]Heat UI related
>> >> requirements & roadmap
>> >>
>> >>
>> >
>> >
>> >
>> >> 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,
>&g

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

[Tim Schnell]

On 11/27/13 10:58 AM, "Fox, Kevin M"  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"  wrote:
>
>>Excerpts from Tim Schnell's message on 27.11.2013 00:44:04:
>>> From: Tim Schnell 
>>> To: "OpenStack Development Mailing List (not for usage questions)"
>>> ,
>>> Date: 27.11.2013 00:47
>>> Subject: Re: [openstack-dev] [heat][horizon]Heat UI related
>>> requirements & roadmap
>>>
>>>
>>
>>
>>
>>> 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 partic

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

[Tim Schnell]

From: Edmund Troche mailto:edmund.tro...@us.ibm.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, November 27, 2013 11:08 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto: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

IBM<http://www.ibm.com/> Software Group | 11501 Burnet Rd. | Austin, TX 78758
* +1.512.286.8977 * T/L 363.8977 * 
edmund.tro...@us.ibm.com<mailto: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 
mailto:thomas.spatz...@de.ibm.com>>
To: "OpenStack Development Mailing List \(not for usage questions\)" 
mailto: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 mailto:tim.schn...@rackspace.com>> wrote 
on 27.11.2013 16:24:18:
> From: Tim Schnell 
> mailto:tim.schn...@rackspace.com>>
> To: "OpenStack Development Mailing List (not for usage questions)"
> mailto: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" 
> mailto:thomas.spatz...@de.ibm.com>>
wr

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

[Tim Schnell]

On 11/27/13 1:17 PM, "Zane Bitter"  wrote:

>On 27/11/13 18:16, Tim Schnell wrote:
>>
>> On 11/27/13 10: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?)
>>
>> 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 bee

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

[Tim Schnell]

On 11/27/13 4:12 PM, "Steve Baker"  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
>> 

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

[Tim Schnell]

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

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


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

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

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

Thanks,
Tim


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

[openstack-dev] [heat] Heater Proposal

[Tim Schnell]

Hi Heaters,

We would like to start a dialog on the general direction of the proposed Heater 
project:
blueprint: https://blueprints.launchpad.net/heat/+spec/heat-template-repo
wiki: https://wiki.openstack.org/wiki/Heat/htr

It is important to us to start the discussion early but please note that the 
wiki is still very much a work-in-progress. I am actively working to clean up 
the use cases and the API spec is just to generate discussion, I expect it to 
change based on general consensus.

We currently have 3 options for starting the Heater project:

  1.  Start Heater as a Stackforge project with a different core team that is 
dedicated to actively working on Heater
  2.  Incubate Heater within the Orchestration umbrella using the existing Heat 
Core team
  3.  Incubate Heater with the Orchestration umbrella, but create a sub-project 
team responsible for reviewing and +2s

The idea behind creating a separate core team either via Stackforge or an 
Orchestration sub-project is so that the people actively working on Heater can 
review and iterate more quickly through code revisions than dumping Heater code 
through the already strained Heat review pipeline.

We are still ironing out the definition of a schema for Heater based on the 
existing use cases in the wiki and we would very much appreciate any input with 
regards to the existing use cases or proposed API spec. In particular, it is 
starting to become apparent that a few of the defined schema are not 
necessarily related to Heater specifically and may make good candidates to 
start a separate discussion on inclusion in the HOT specification.

The following things, specifically, would add value to the HOT specification in 
general (copied from the wiki if you need further context):

application:
   name: Wordpress
   version: 3.6.1
   flavor: Single Linux server with WordPress 3.6.1 and MySQL 5.5
   weight: 3
 icons:
 - href: 
https://600861890ddb34a8670a-744765205721eed93c384dae790e86aa.ssl.cf2.rackcdn.com/wordpress-tattoo.png
   type: default
 - href: 
https://600861890ddb34a8670a-744765205721eed93c384dae790e86aa.ssl.cf2.rackcdn.com/wordpress-icon-20x20.png
   type: small
 keywords:
 - wordpress
 - mysql

documentation:
   abstract:
 some abstract...
   guide:
 This blueprint includes a single server running Wordpress with Varnish.
 This blueprint's performance has not been measured.
   instructions:
 If you're new to WordPress, the
 documentation will step you through the process of logging into the
 admin panel, customizing your blog, and changing your theme.

Keywords has already been the subject of another mailing list conversation so 
let's ignore that one for the moment. If there is general consensus that we 
should at least discuss application, icons, and documentation as possible 
candidates for the HOT syntax then I will start a separate mailing list thread 
to detail out the use cases.

The original thought was, other things like template versioning information and 
keystone roles for permissions are very obviously related to Heater. Heater 
will use those things to make decisions about how it works. But application 
information, icons and documentation are not things that Heater cares about. 
Heat also does not care about these things but the downstream user interface 
does care about these things and a human looking at the Heat template would be 
able to gather valuable information from these things as well.

Obviously, the actual structure and use cases for these things would need to be 
vetted before inclusion in the HOT syntax but let's discuss the more general 
idea that the HOT syntax should include things that Heat (or Heater) does not 
care about but can prove to add real value to the user experience at some point 
in a user's interaction with Heat.

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] [glance] Heater Proposal

[Tim Schnell]

On 12/5/13 11:33 AM, "Randall Burt"  wrote:

>On Dec 5, 2013, at 11:10 AM, Clint Byrum 
> wrote:
>
>> Excerpts from James Slagle's message of 2013-12-05 08:35:12 -0800:
>>> On Thu, Dec 5, 2013 at 11:10 AM, Clint Byrum  wrote:
 Excerpts from Monty Taylor's message of 2013-12-04 17:54:45 -0800:
> Why not just use glance?
> 
 
 I've asked that question a few times, and I think I can collate the
 responses I've received below. I think enhancing glance to do these
 things is on the table:
>>> 
>>> I'm actually interested in the use cases laid out by Heater from both
>>> a template perspective and image perspective.  For the templates, as
>>> Robert mentioned, Tuskar needs a solution for this requirement, since
>>> it's deploying using templates.  For the images, we have the concept
>>> of a "golden" image in TripleO and are heavily focused on image based
>>> deployments.  Therefore, it seems to make sense that TripleO also
>>> needs a way to version/tag known good images.
>>> 
>>> Given that, I think it makes sense  to do this in a way so that it's
>>> consumable for things other than just templates.  In fact, you can
>>> almost s/template/image/g on the Heater wiki page, and it pretty well
>>> lays out what I'd like to see for images as well.
>>> 
 1. Glance is for big blobs of data not tiny templates.
 2. Versioning of a single resource is desired.
 3. Tagging/classifying/listing/sorting
 4. Glance is designed to expose the uploaded blobs to nova, not users
 
 My responses:
 
 1: Irrelevant. Smaller things will fit in it just fine.
 
 2: The swift API supports versions. We could also have git as a
 backend.
>>> 
>>> I would definitely like to see a git backend for versioning.  No
>>> reason to reimplement a different solution for what already works
>>> well.  I'm not sure we'd want to put a whole image into git though.
>>> Perhaps just it's manifest (installed components, software versions,
>>> etc) in json format would go into git, and that would be associated
>>> back to the binary image via uuid.  That would even make it easy to
>>> diff changes between versions, etc.
>>> 
>> 
>> Right, git for a big 'ol image makes little sense.
>> 
>> I'm suggesting that one might want to have two glances, one for images
>> which just uses swift versions and would just expose a list of versions,
>> and one for templates which would use git and thus expose more features
>> like a git remote for the repo. I'm not sure if glance has embraced the
>> extension paradigm yet, but this would fall nicely into it.
>
>Alternatively, Glance could have configurable backends for each image
>type allowing for optimization without the (often times messy) extension
>mechanism? This is assuming it doesn't do this already - I really need to
>start digging here. In the spirit of general OpenStack architectural
>paradigms, as long as the service exposes a consistent interface for
>templates that includes versioning support, the back-end store and
>(possibly) the versioning "engine" should certainly be configurable.
>Swift probably makes a decent first/default implementation.

I'm not sure why we are attempting to fit a round peg in a square hole
here. Glance's entire design is built around serving images and there
absolutely is a difference between serving BLOBs versus relatively small
templates. Just look at the existing implementations, Heat already stores
the template directly in the database while Glance stores the blob in an
external file system.

I'm not opposed to having Glance as an optional configurable backend for
Heater but if you look at the existing database models for Glance, an
entirely separate schema would have to be created to support templates. I
also think that having Heater as a layer above Glance or whatever other
backend would allow for the flexibility for Heater's requirements to
diverge in the future from requirements that might make sense for images
but not templates.

-Tim

>
 This feels like something we can add as an optional feature
 without exploding Glance's scope and I imagine it would actually be a
 welcome feature for image authors as well. Think about Ubuntu
maintaining
 official images. If they can keep the ID the same and just add a
version
 (allowing users to lock down to a version if updated images cause
issue)
 that seems like a really cool feature for images _and_ templates.
 
 3: I'm sure glance image users would love to have those too.
 
 4: Irrelevant. Heat will need to download templates just like nova,
and
 making images publicly downloadable is also a thing in glance.
 
 It strikes me that this might be a silo problem instead of an
 actual design problem. Folk should not be worried about jumping into
 Glance and adding features. Unless of course the Glance folk have
 reservations? (adding glance tag to the subject)
>>> 
>>> I'm +1 for adding th

Re: [openstack-dev] [heat] [glance] Heater Proposal

[Tim Schnell]

On 12/5/13 12:17 PM, "Clint Byrum"  wrote:


>Excerpts from Tim Schnell's message of 2013-12-05 09:49:03 -0800:
>> 
>> On 12/5/13 11:33 AM, "Randall Burt"  wrote:
>> 
>> >On Dec 5, 2013, at 11:10 AM, Clint Byrum 
>> > wrote:
>> >
>> >> Excerpts from James Slagle's message of 2013-12-05 08:35:12 -0800:
>> >>> On Thu, Dec 5, 2013 at 11:10 AM, Clint Byrum 
>>wrote:
>>  Excerpts from Monty Taylor's message of 2013-12-04 17:54:45 -0800:
>> > Why not just use glance?
>> > 
>>  
>>  I've asked that question a few times, and I think I can collate the
>>  responses I've received below. I think enhancing glance to do these
>>  things is on the table:
>> >>> 
>> >>> I'm actually interested in the use cases laid out by Heater from
>>both
>> >>> a template perspective and image perspective.  For the templates, as
>> >>> Robert mentioned, Tuskar needs a solution for this requirement,
>>since
>> >>> it's deploying using templates.  For the images, we have the concept
>> >>> of a "golden" image in TripleO and are heavily focused on image
>>based
>> >>> deployments.  Therefore, it seems to make sense that TripleO also
>> >>> needs a way to version/tag known good images.
>> >>> 
>> >>> Given that, I think it makes sense  to do this in a way so that it's
>> >>> consumable for things other than just templates.  In fact, you can
>> >>> almost s/template/image/g on the Heater wiki page, and it pretty
>>well
>> >>> lays out what I'd like to see for images as well.
>> >>> 
>>  1. Glance is for big blobs of data not tiny templates.
>>  2. Versioning of a single resource is desired.
>>  3. Tagging/classifying/listing/sorting
>>  4. Glance is designed to expose the uploaded blobs to nova, not
>>users
>>  
>>  My responses:
>>  
>>  1: Irrelevant. Smaller things will fit in it just fine.
>>  
>>  2: The swift API supports versions. We could also have git as a
>>  backend.
>> >>> 
>> >>> I would definitely like to see a git backend for versioning.  No
>> >>> reason to reimplement a different solution for what already works
>> >>> well.  I'm not sure we'd want to put a whole image into git though.
>> >>> Perhaps just it's manifest (installed components, software versions,
>> >>> etc) in json format would go into git, and that would be associated
>> >>> back to the binary image via uuid.  That would even make it easy to
>> >>> diff changes between versions, etc.
>> >>> 
>> >> 
>> >> Right, git for a big 'ol image makes little sense.
>> >> 
>> >> I'm suggesting that one might want to have two glances, one for
>>images
>> >> which just uses swift versions and would just expose a list of
>>versions,
>> >> and one for templates which would use git and thus expose more
>>features
>> >> like a git remote for the repo. I'm not sure if glance has embraced
>>the
>> >> extension paradigm yet, but this would fall nicely into it.
>> >
>> >Alternatively, Glance could have configurable backends for each image
>> >type allowing for optimization without the (often times messy)
>>extension
>> >mechanism? This is assuming it doesn't do this already - I really need
>>to
>> >start digging here. In the spirit of general OpenStack architectural
>> >paradigms, as long as the service exposes a consistent interface for
>> >templates that includes versioning support, the back-end store and
>> >(possibly) the versioning "engine" should certainly be configurable.
>> >Swift probably makes a decent first/default implementation.
>> 
>> I'm not sure why we are attempting to fit a round peg in a square hole
>> here. Glance's entire design is built around serving images and there
>> absolutely is a difference between serving BLOBs versus relatively small
>> templates. Just look at the existing implementations, Heat already
>>stores
>> the template directly in the database while Glance stores the blob in an
>> external file system.
>> 
>
>What aspects of circles and squares do you find match glance and the
>Heater problem space? :-P
>
>If this were as simple as geometric shape matching, my 4-year old could
>do it, right? :) Let's use analogies, I _love_ analogies, but perhaps
>lets be more careful about whether they actually aid the discussion.
>
>The blobs in the heat database are going to be a problem actually. I've
>dealt with a very similar relatively large system, storing millions
>of resumes in a single table for a job candidate database. It performs
>horribly even if you shard. These weren't 50MB resumes, these were 30 -
>50 kB resumes. That is because every time you need to pull all the rows
>you have to pull giant amounts of data and generally just blow out all
>of the caches, buffers, etc. Keystone's token table for the sql token
>backend has the same problem. RDBMS's are good at storing and retrieving
>rows of relatively predictably sized data. They suck for documents.
>
>Heat would do well to just store template references and fetch them in
>the rare cases where the raw templates are need

Re: [openstack-dev] [heat] [glance] Heater Proposal

[Tim Schnell]

The original intention was to propose the Heater functionality as part of Heat. 
I would just like to clarify that having Heater as a separate project is not 
because of the impact of the gerrit reviews. The proposal for a separate Core 
team or sub-project team was to solve the impact on reviews. Heater is now 
being proposed as a separate project from Heat because previous conversations 
with the Heat Core team has lead us to believe that Heat is not in the business 
of managing templates.

Thanks,
Tim

From: Tim Bell mailto:tim.b...@cern.ch>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, December 5, 2013 2:13 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [heat] [glance] Heater Proposal

Completely agree with Brad… a new project for this is not what is needed.

>From an operator’s point of view, it is a REAL, REAL, REAL pain to be 
>configuring yet another project, yet another set of Puppet/Chef recipes, 
>additional monitoring, service nodes, new databases, more documentation, 
>further packages, pre-requisites and tough divergent roles follow…

While I appreciate that there is an impact from having reviews, this should not 
be the cause for creating more complexity for those who wish to use the 
functionality.

I’d also suggest the Heater guys talk to the Murano guys since my ideal 
scenario is for a simple user kiosk where I can ask for an app, be asked for 
some configuration details and then deploy. The two projects appear to be 
heading towards a converged solution.

Tim

From: Brad Topol [mailto:bto...@us.ibm.com]
Sent: 05 December 2013 20:06
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [heat] [glance] Heater Proposal

Lots of good discussion on this topic.   One thing I would like to point out is 
that we get feedback that OpenStack has too many projects as it is and 
customers get confused on how much of OpenStack they need to install.  So in 
the spirit of trying to help insure OpenStack does not continue to reinforce 
this perception, I am hoping that Heater functionality finds a home in either 
Glance or Heat.  I don't have a preference of which.   Either of these is 
superior to starting a new project if it can be avoided.

Thanks,

Brad

Brad Topol, Ph.D.
IBM Distinguished Engineer
OpenStack
(919) 543-0646
Internet:  bto...@us.ibm.com
Assistant: Kendra Witherspoon (919) 254-0680



From:Randall Burt 
mailto:randall.b...@rackspace.com>>
To:"OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date:12/05/2013 12:09 PM
Subject:Re: [openstack-dev] [heat] [glance] Heater Proposal




On Dec 5, 2013, at 10:10 AM, Clint Byrum 
mailto:cl...@fewbar.com>>
wrote:

> Excerpts from Monty Taylor's message of 2013-12-04 17:54:45 -0800:
>> Why not just use glance?
>>
>
> I've asked that question a few times, and I think I can collate the
> responses I've received below. I think enhancing glance to do these
> things is on the table:
>
> 1. Glance is for big blobs of data not tiny templates.
> 2. Versioning of a single resource is desired.
> 3. Tagging/classifying/listing/sorting
> 4. Glance is designed to expose the uploaded blobs to nova, not users
>
> My responses:
>
> 1: Irrelevant. Smaller things will fit in it just fine.

Fitting is one thing, optimizations around particular assumptions about the 
size of data and the frequency of reads/writes might be an issue, but I admit 
to ignorance about those details in Glance.

> 2: The swift API supports versions. We could also have git as a
> backend. This feels like something we can add as an optional feature
> without exploding Glance's scope and I imagine it would actually be a
> welcome feature for image authors as well. Think about Ubuntu maintaining
> official images. If they can keep the ID the same and just add a version
> (allowing users to lock down to a version if updated images cause issue)
> that seems like a really cool feature for images _and_ templates.

Agreed, though one could argue that using image names and looking up ID's or 
just using ID's as appropriate "sort of" handle this use case, but I agree that 
having image versioning seems a reasonable feature for Glance to have as well.

> 3: I'm sure glance image users would love to have those too.

And image metadata is already there so we don't have to go through those 
discussions all over again ;).

> 4: Irrelevant. Heat will need to download templates just like nova, and
> making images publicly downloadable is also a thing in glance.

Yeah, this was the kicker for me. I'd been thinking of adding the 
tenancy/public/private templates use case to the HeatR spec and realized that 
this was a good argument for Glance sin

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

[Tim Schnell]

To resolve this thread, I have created 5 blueprints based on this mailing
list discussion. I have attempted to distill the proposed specification
down to what seemed generally agreed upon but if you feel strongly that I
have incorrectly captured something let's talk about it!

Here are the blueprints:

1) Stack Keywords
blueprint: https://blueprints.launchpad.net/heat/+spec/stack-keywords
spec: https://wiki.openstack.org/wiki/Heat/UI#Stack_Keywords

2) Parameter Grouping and Ordering
blueprint: 
https://blueprints.launchpad.net/heat/+spec/parameter-grouping-ordering
spec: 
https://wiki.openstack.org/wiki/Heat/UI#Parameter_Grouping_and_Ordering

3) Parameter Help Text
blueprint: 
https://blueprints.launchpad.net/heat/+spec/add-help-text-to-template
spec: https://wiki.openstack.org/wiki/Heat/UI#Help_Text

4) Parameter Label
blueprint: 
https://blueprints.launchpad.net/heat/+spec/add-parameter-label-to-template
spec: https://wiki.openstack.org/wiki/Heat/UI#Parameter_Label


This last blueprint did not get as much discussion so I have added it with
the discussion flag set. I think this will get more important in the
future but I don't need to implement right now. I'd love to hear more
thoughts about it.

5) Get Parameters API Endpoint
blueprint: 
https://blueprints.launchpad.net/heat/+spec/get-parameters-from-api
spec: 
https://wiki.openstack.org/wiki/Heat/UI#New_API_Endpoint_for_Returning_Temp
late_Parameters

Thanks,
Tim

On 11/28/13 4:55 AM, "Zane Bitter"  wrote:

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

[Tim Schnell]

On 12/6/13 4:32 PM, "Randall Burt"  wrote:

>I hope I'm not re-opening worm cans here, and that's not my intent, but I
>just wanted to get a little clarification in-line below:
>
>On Dec 6, 2013, at 3:24 PM, Tim Schnell 
> wrote:
>
>> To resolve this thread, I have created 5 blueprints based on this
>>mailing
>> list discussion. I have attempted to distill the proposed specification
>> down to what seemed generally agreed upon but if you feel strongly that
>>I
>> have incorrectly captured something let's talk about it!
>> 
>> Here are the blueprints:
>> 
>> 1) Stack Keywords
>> blueprint: https://blueprints.launchpad.net/heat/+spec/stack-keywords
>> spec: https://wiki.openstack.org/wiki/Heat/UI#Stack_Keywords
>
>As proposed, these look like template keywords and not stack keywords.
>
>I may be mis-remembering the conversation around this, but it would seem
>to me this mixes tagging templates and tagging stacks. In my mind, these
>are separate things. For the stack part, it seems like I could just pass
>something like "--keyword blah" multiple times to python-heatclient and
>not have to edit the template I'm passing. This lets me organize my
>stacks the way I want rather than relying on the template author (who may
>not be me) to organize things for me. Alternatively, I'd at least like
>the ability to accept, replace, and/or augment the keywords the template
>author proposes.
There was discussion about the particular implementation which didn't feel
quite resolved to me. The 2 options being, putting keywords in the
template and then parsing them out to store separately in the database and
what you suggest, passing them in along with the template.

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

I didn't change the initial proposal because after scoping the use case to
stack keywords I didn't notice any major negative response. Does including
the keywords within the template cause major heartburn?
>
>> 
>> 2) Parameter Grouping and Ordering
>> blueprint: 
>> https://blueprints.launchpad.net/heat/+spec/parameter-grouping-ordering
>> spec: 
>> https://wiki.openstack.org/wiki/Heat/UI#Parameter_Grouping_and_Ordering
>> 
>> 3) Parameter Help Text
>> blueprint: 
>> https://blueprints.launchpad.net/heat/+spec/add-help-text-to-template
>> spec: https://wiki.openstack.org/wiki/Heat/UI#Help_Text
>> 
>> 4) Parameter Label
>> blueprint: 
>> 
>>https://blueprints.launchpad.net/heat/+spec/add-parameter-label-to-templa
>>te
>> spec: https://wiki.openstack.org/wiki/Heat/UI#Parameter_Label
>> 
>> 
>> This last blueprint did not get as much discussion so I have added it
>>with
>> the discussion flag set. I think this will get more important in the
>> future but I don't need to implement right now. I'd love to hear more
>> thoughts about it.
>> 
>> 5) Get Parameters API Endpoint
>> blueprint: 
>> https://blueprints.launchpad.net/heat/+spec/get-parameters-from-api
>> spec: 
>> 
>>https://wiki.openstack.org/wiki/Heat/UI#New_API_Endpoint_for_Returning_Te
>>mp
>> late_Parameters
>
>History around validate_template aside, I wonder if this doesn't re-open
>the discussion around having an endpoint that will translate an entire
>template into the native format (HOT). I understand that the idea is that
>we normalize parameter values to relieve user interfaces from having to
>understand several formats supported by Heat, but it just seems to me
>that there's a more general use case here.

Agreed, I can definitely see future use cases that would support an
endpoint to converge the entire template. :)
>
>> 
>> Thanks,
>> Tim
>
>I know its probably nit-picky, but I would prefer these specs be
>individual wiki pages instead of lumped all together. At any rate, thanks
>for organizing all this!

Doh! Will do next go round.

Thanks,
Tim
>
>> 
>> On 11/28/13 4:55 AM, "Zane Bitter"  wrote:
>> 
>>> On 27/11/13 23:37, Fox, Kevin M wrote:
>>>> Hmm... Yeah. when you tell heat client the url to a template file, you
>>>> could set a flag telling the heat client it is in a git repo. It could
>>>> then automatically look for repo information and set a stack metadata
>>>> item pointing back to it.
>>> 
>>> Or just

Re: [openstack-dev] [Horizon] Support for Django 1.6

[Tim Schnell]

On 12/23/13 5:02 AM, "Thomas Goirand"  wrote:


>On 12/20/2013 04:39 PM, Matthias Runge wrote:
>> On 12/19/2013 04:45 PM, Thomas Goirand wrote:
>>> Hi,
>>>
>>> Sid has Django 1.6. Is it planned to add support for it? I currently
>>> don't know what to do with the Horizon package, as it's currently
>>> broken... :(
>>>
>>> Thomas
>> Yes, there are two patches available, one for horizon[1] and one for
>> django_openstack_auth[2]
>> 
>> If both are in, we can start gating on django-1.6 as well.
>> 
>> [1] https://review.openstack.org/#/c/58947/
>> [2] https://review.openstack.org/#/c/58561/
>> 
>> Matthias
>
>Hi Matthias,
>
>Thanks a lot for these pointers. I tried patching openstack-auth. While
>it did work in Wheezy (with Django 1.4), all the 80 unit tests are
>failing in Sid, with the following error:
>
>ImportError: No module named defaults
>
>while trying to do:
>
>from django.conf.urls.defaults import patterns, url
>
>Is there anything that I missed? Maybe a missing Django python module?

It looks like the defaults module has been removed in Django 1.6. It was
deprecated in Django 1.4. You should be able to just change these imports
to:

from django.conf.urls import patterns, url

https://docs.djangoproject.com/en/dev/releases/1.4/#django-conf-urls-defaul
ts


-Tim
>
>Cheers,
>
>Thomas
>
>
>___
>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] [OpenStack][HEAT][Dashboard] Edit JSON tempalte on OpenStack Dashboard

[Tim Schnell]

On 1/15/14 9:01 AM, "Liz Blanchard"  wrote:


>
>On Jan 9, 2014, at 4:41 AM, Jay Lau  wrote:
>
>
>My bad, the image cannot be viewed.
>
>
>Upload again.
>
>
>
>Thanks,
>
>
>Jay
>
>
>
>2014/1/9 Jay Lau 
>
>Hi,
>
>
>Now when using OpenStack dashboard to launch a stack, we need to first
>import the template then create the stack, but there is no way to enable
>admin to view/modify the template.

Hi Jay,

Sorry I meant to respond to this a few days ago. Currently, in the
dashboard you have the ability to copy/paste a template into a text area
and then edit it before you attempt the stack-create. This seems to solve
the use case that you have mentioned although I agree that there is room
for improvement in the user experience.

The reason I bring up the distinction is because the template that you
reference below has a much broader scope. It includes storing and managing
templates for future use. If you are intending to add all of this
functionality into the Dashboard then I would suggest waiting for a
template storage solution to get done. There is currently a blueprint and
discussion happening in Glance to take on this ability and then I would
imagine that the Dashboard can consume it.

see: 
https://blueprints.launchpad.net/glance/+spec/metadata-artifact-repository

If you are intending to simply add an additional page for editing the
template if the user chooses to retrieve it via the URL option then my
only suggestion would be to have a flag that gets stored in the session
that allows the user to bypass the editing step for launching templates
since some users will never need to edit templates.

>
>
>What about add a new page between import template and launch stack to
>give admin an opportunity to edit the template?
>
>
>I noticed that we already have a blueprint tracing this:
>https://blueprints.launchpad.net/horizon/+spec/heat-template-management
>
>
>
>
>I did some investigation, seems we can leverage
>http://jsoneditoronline.org/  to enable
>OpenStack dashboard have this ability (Only for JSON template).
>
>
>
>Hi Jay,
>
>
>I really like the idea of allowing users to edit these templates easily
>right through the dashboard. Are all template files in JSON? I would say
>we should try to find a solution to add to the dashboard that would
>support all (or as many as possible) formats
> of template that we can.

I agree with Liz here, templates can be in JSON or YAML format so if we do
add a javascript library to provide syntax highlighting and things then I
would want it to work with YAML as well as JSON.

-Tim

>
>
>Best,
>Liz
>
>
>
>
>
>
>
>
>
>Thanks,
>
>
>Jay
>
>
>
>
>
>
>___
>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] [OpenStack][HEAT][Dashboard][Horizon] Edit JSON tempalte on OpenStack Dashboard

[Tim Schnell]

On 1/15/14 10:05 AM, "Jay Lau"  wrote:


>Thanks Tim and Liz, comments in line.
>
>
>
>2014/1/15 Tim Schnell 
>
>On 1/15/14 9:01 AM, "Liz Blanchard"  wrote:
>
>
>>
>>On Jan 9, 2014, at 4:41 AM, Jay Lau  wrote:
>>
>>
>>My bad, the image cannot be viewed.
>>
>>
>>Upload again.
>>
>>
>>
>>Thanks,
>>
>>
>>Jay
>>
>>
>>
>>2014/1/9 Jay Lau 
>>
>>Hi,
>>
>>
>>Now when using OpenStack dashboard to launch a stack, we need to first
>>import the template then create the stack, but there is no way to enable
>>admin to view/modify the template.
>
>
>Hi Jay,
>
>Sorry I meant to respond to this a few days ago. Currently, in the
>dashboard you have the ability to copy/paste a template into a text area
>and then edit it before you attempt the stack-create. This seems to solve
>the use case that you have mentioned although I agree that there is room
>for improvement in the user experience.
>
>The reason I bring up the distinction is because the template that you
>reference below has a much broader scope. It includes storing and managing
>templates for future use. If you are intending to add all of this
>functionality into the Dashboard then I would suggest waiting for a
>template storage solution to get done. There is currently a blueprint and
>discussion happening in Glance to take on this ability and then I would
>imagine that the Dashboard can consume it.
>
>see:
>https://blueprints.launchpad.net/glance/+spec/metadata-artifact-repository
>
>If you are intending to simply add an additional page for editing the
>template if the user chooses to retrieve it via the URL option then my
>only suggestion would be to have a flag that gets stored in the session
>that allows the user to bypass the editing step for launching templates
>since some users will never need to edit templates.
>
>
>@Tim, I think that it might be ok to enable admin still be able to see
>the overall JSON/YAML template by the edit page even if s/he does not
>want to edit it. ;-)
>
>I'm planning to add both edit/create page to heat, and I noticed that AWS
>already have such feature:
>
>http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-using-cl
>oudformer.html 
><http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-using-c
>loudformer.html>, I'm now trying if we can leverage some from it.
>
>
>So I think that the dashboard should probably add a new button named as
>create. Yes, now we cannot store template, so my thinking is that once
>admin create template finished, then s/he can simply export it and save
>it locally for future use.

So I'm having trouble following your train of thought. Implementing some
CloudFormer-like functionality is very different from the initial proposal
of being able to edit a template after it is imported via a URL. What
functionality is the user gaining by being able to write a template in the
Dashboard as opposed to just writing it locally in the first place?

If the answer is that you are wanting to actually build out a GUI that
retrieves existing nova instances or Heat resources types I think we need
to take some time to fully flesh out the concept. I would imagine that
building out a CloudFormer Openstack project might actually either belong
in Heat or maybe a new Stackforge project but probably not in
Horizon/Dashboard. I could be wrong but I think that the Dashboard should
be in the business of consuming Openstack APIs and not embedding
completely new functionality in the UI.

I could be completely off-base but I think a very clear, organized
proposal is warranted in this case.

-Tim
>
>
>
>>
>>
>>What about add a new page between import template and launch stack to
>>give admin an opportunity to edit the template?
>>
>>
>>I noticed that we already have a blueprint tracing this:
>>https://blueprints.launchpad.net/horizon/+spec/heat-template-management
>><https://blueprints.launchpad.net/horizon/+spec/heat-template-management>
>>
>>
>>
>>I did some investigation, seems we can leverage
>
>>http://jsoneditoronline.org/ <http://jsoneditoronline.org/> to enable
>>OpenStack dashboard have this ability (Only for JSON template).
>>
>>
>>
>>Hi Jay,
>>
>>
>>I really like the idea of allowing users to edit these templates easily
>>right through the dashboard. Are all template files in JSON? I would say
>>we should try to find a solution to add to the dashboard that would
>>support all (or as many as possible) formats
>> of template that we can.
>
>
>I agree with Liz he

Re: [openstack-dev] [HEAT] Discussion: How to list nested stack resources.

[Tim Schnell]

Hi Nilakhya,

As Randall mentioned we did discuss this exact issue at the summit. I was
planning on putting a blueprint together today to continue the discussion.
The Stack Preview call is already doing the necessary recursion to gather
the resources so we discussed being able to pass a stack id to the preview
endpoint to get all of the resources.

However, after thinking about it some more, I agree with Randall that
maybe this should be an extra query parameter passed to the resource-list
call. I'Ll have the blueprint up later today, unless you have already
started on it.

Thanks,
Tim Schnell
Software Developer
Rackspace





On 5/19/14 10:04 AM, "Randall Burt"  wrote:

>Nilakhya, We discussed this a bit at the summit and I think the consensus
>was that this would be a good thing to do by passing a flag to
>resource-list that would "flatten" the structure of nested stacks in the
>call. Tim Schnell brought this up as well and may be interested in
>helping define the use case and spec.
>
>On May 14, 2014, at 4:32 PM, Nilakhya Chatterjee
> wrote:
>
>> Hi All,
>> 
>> I recently tried to create a nested stack with the following example :
>> 
>> http://paste.openstack.org/show/79156/
>> 
>> heat resource-list  gives only "MyStack" but intention should be to
>>list all the resources created by the nested templates, as also pointed
>>by the command help:
>> 
>> resource-list   Show list of resources belonging to a stack
>> 
>> 
>> Let me know if this requires a BP to be created for discussion.
>> 
>> Thanks.
>> 
>> -- 
>> 
>> Nilakhya | Consultant Engineering
>> GlobalLogic
>> P +x.xxx.xxx.  M +91.989.112.5770  S skype
>> www.globallogic.com
>> 
>> http://www.globallogic.com/email_disclaimer.txt
>> ___
>> 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] Discussion: How to list nested stack resources.

[Tim Schnell]

On 5/19/14 12:35 PM, "Randall Burt"  wrote:


>On May 19, 2014, at 11:39 AM, Steven Hardy 
> wrote:
>
>> On Mon, May 19, 2014 at 03:26:22PM +, Tim Schnell wrote:
>>> Hi Nilakhya,
>>> 
>>> As Randall mentioned we did discuss this exact issue at the summit. I
>>>was
>>> planning on putting a blueprint together today to continue the
>>>discussion.
>>> The Stack Preview call is already doing the necessary recursion to
>>>gather
>>> the resources so we discussed being able to pass a stack id to the
>>>preview
>>> endpoint to get all of the resources.
>>> 
>>> However, after thinking about it some more, I agree with Randall that
>>> maybe this should be an extra query parameter passed to the
>>>resource-list
>>> call. I'Ll have the blueprint up later today, unless you have already
>>> started on it.
>> 
>> Note there is a patch from Anderson/Richard which may help with this:
>> 
>> https://review.openstack.org/#/c/85781/
>> 
>> The idea was to enable easier introspection of resources backed by
>>nested
>> stacks in a UI, but it could be equally useful to generate a "tree"
>> resource view in the CLI client by walking the links.
>> 
>> This would obviously be less efficient than recursing inside the engine,
>> but arguably the output would be much more useful if it retains the
>>nesting
>> structure, as opposed to presenting a fully flattened "soup" of
>>resources
>> with no idea which stack/layer they belong to.
>> 
>> Steve
>
>Could we simply add stack name/id to this output if the flag is passed? I
>agree that we currently have the capability to traverse the tree
>structure of nested stacks, but several folks have requested this
>capability, mostly for UI/UX purposes. It would be faster if you want the
>flat structure and we still retain the capability to create your own
>tree/widget/whatever by following the links. Also, I think its best to
>include this in the API directly since not all users are integrating
>using the python-heatclient.

+1 for adding the stack name/id to the output to maintain a reference to
the initial stack that the resource belongs to. The original stated
use-case that I am aware of was to have a flat list of all resources
associated with a stack to be displayed in the UI when the user prompts to
delete a stack. This would prevent confusion about what and why different
resources are being deleted due to the stack delete.

This use-case does not require any information about the nested stacks but
I can foresee that information being useful in the future. I think a
flattened data structure (with a reference to stack id) is still the most
efficient solution. The patch landed by Anderson/Richard provides an
alternate method to drill down into nested stacks if the hierarchy is
important information though this is not the optimal solution in this case.

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] Discussion: How to list nested stack resources.

[Tim Schnell]

Blueprint: 
https://blueprints.launchpad.net/heat/+spec/explode-nested-resources

Spec: https://wiki.openstack.org/wiki/Heat/explode-resource-list

Tim

On 5/19/14 1:53 PM, "Tim Schnell"  wrote:

>On 5/19/14 12:35 PM, "Randall Burt"  wrote:
>
>
>>On May 19, 2014, at 11:39 AM, Steven Hardy 
>> wrote:
>>
>>> On Mon, May 19, 2014 at 03:26:22PM +, Tim Schnell wrote:
>>>> Hi Nilakhya,
>>>> 
>>>> As Randall mentioned we did discuss this exact issue at the summit. I
>>>>was
>>>> planning on putting a blueprint together today to continue the
>>>>discussion.
>>>> The Stack Preview call is already doing the necessary recursion to
>>>>gather
>>>> the resources so we discussed being able to pass a stack id to the
>>>>preview
>>>> endpoint to get all of the resources.
>>>> 
>>>> However, after thinking about it some more, I agree with Randall that
>>>> maybe this should be an extra query parameter passed to the
>>>>resource-list
>>>> call. I'Ll have the blueprint up later today, unless you have already
>>>> started on it.
>>> 
>>> Note there is a patch from Anderson/Richard which may help with this:
>>> 
>>> https://review.openstack.org/#/c/85781/
>>> 
>>> The idea was to enable easier introspection of resources backed by
>>>nested
>>> stacks in a UI, but it could be equally useful to generate a "tree"
>>> resource view in the CLI client by walking the links.
>>> 
>>> This would obviously be less efficient than recursing inside the
>>>engine,
>>> but arguably the output would be much more useful if it retains the
>>>nesting
>>> structure, as opposed to presenting a fully flattened "soup" of
>>>resources
>>> with no idea which stack/layer they belong to.
>>> 
>>> Steve
>>
>>Could we simply add stack name/id to this output if the flag is passed? I
>>agree that we currently have the capability to traverse the tree
>>structure of nested stacks, but several folks have requested this
>>capability, mostly for UI/UX purposes. It would be faster if you want the
>>flat structure and we still retain the capability to create your own
>>tree/widget/whatever by following the links. Also, I think its best to
>>include this in the API directly since not all users are integrating
>>using the python-heatclient.
>
>+1 for adding the stack name/id to the output to maintain a reference to
>the initial stack that the resource belongs to. The original stated
>use-case that I am aware of was to have a flat list of all resources
>associated with a stack to be displayed in the UI when the user prompts to
>delete a stack. This would prevent confusion about what and why different
>resources are being deleted due to the stack delete.
>
>This use-case does not require any information about the nested stacks but
>I can foresee that information being useful in the future. I think a
>flattened data structure (with a reference to stack id) is still the most
>efficient solution. The patch landed by Anderson/Richard provides an
>alternate method to drill down into nested stacks if the hierarchy is
>important information though this is not the optimal solution in this
>case.
>
>Tim
>>
>>
>>___
>>OpenStack-dev mailing list
>>OpenStack-dev@lists.openstack.org
>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>___
>OpenStack-dev mailing list
>OpenStack-dev@lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [Heat] Network topologies

[Tim Schnell]

Hi Edgar,

It seems like this blueprint is related more to building an api that
manages a network topology more than one that needs to build out the
dependencies between resources to help create the network topology. If we
are talking about just an api to "save", "duplicate", and "share" these
network topologies then I would agree that this is not something that Heat
currently does or should do necessarily.

I have been focusing primarily on front-end work for Heat so I apologize
if these questions have already been answered. How is this API related to
the existing network topology in Horizon? The existing network topology
can already define the relationships and dependencies using Neutron I'm
assuming so there is no apparent need to use Heat to gather this
information. I'm a little confused as to the scope of the discussion, is
that something that you are potentially interested in changing?

Steve, Clint and Zane can better answer whether or not Heat wants to be in
the business of managing existing network topologies but from my
perspective I tend to agree with your statement that if you needed Heat to
help describe the relationships between network resources then that might
be duplicated effort but if don't need Heat to do that then this blueprint
belongs in Neutron.

Thanks,
Tim





On 10/29/13 1:32 AM, "Steven Hardy"  wrote:

>On Mon, Oct 28, 2013 at 01:19:13PM -0700, Edgar Magana wrote:
>> Hello Folks,
>> 
>> Thank you Zane, Steven and Clint for you input.
>> 
>> Our main goal in this BP is to provide networking users such as Heat (we
>> consider it as a neutron user) a better and consolidated network
>>building
>> block in terms of an API that you could use for orchestration of
>> application-driven requirements. This building block does not add any
>> "intelligence" to the network topology because it does not have it and
>> this is why I think this BP is different from the work that you are
>>doing
>> in Heat.
>
>So how do you propose to handle dependencies between elements in the
>topology, e.g where things need to be created/deleted in a particular
>order, or where one resource must be in a particular state before another
>can be created?
>
>> The network topologies BP is not related to the Neutron Network Service
>> Insertion BP:
>> 
>>https://blueprints.launchpad.net/neutron/+spec/neutron-services-insertion
>>-c
>> haining-steering
>
>So I wasn't saying they were related, only that they both, arguably, may
>have some scope overlap with what Heat is doing.
>
>> I do agree with Steven that the insertion work add "intelligence"
>> (explicit management of dependencies, state and workflow) to the network
>> orchestration simply because user will need to know the insertion
>> mechanism and dependencies between Network Advances Services, that work
>>is
>> more into Heat space that the BP that I am proposing but that is just my
>> opinion.
>
>This seems a good reason to leverage the work we're doing rather than
>reinventing it.  I'm not arguing that Heat should necessarily be the
>primary interface to such functionality, only that Heat could (and
>possibly
>should) be used to do the orchestration aspects.
>
>> However, is there a session where I can discuss this BP with you guys?,
>> the session that I proposed in Neutron has been rejected because it was
>> considered by the PTL as an overlapping work with the Heat goals,
>> therefore I wanted to know if you can to discuss it or I just simple go
>> ahead and start the implementation. I do still believe it can be easily
>> implemented in Neutron and then exposed to Heat but I am really looking
>> forward to having a broader discussion.
>
>I don't think we have any sessions directly related to Neutron, but we are
>definitely interested in discussing this (and other Neutron BPs which may
>have integration points requiring orchestration).
>
>I suggest we have an informal breakout session with those interested on
>Tuesday or Wednesday, or it could be a topic which Steve Baker may
>consider
>for this placeholder session:
>
>http://summit.openstack.org/cfp/details/360
>
>Steve
>
>___
>OpenStack-dev mailing list
>OpenStack-dev@lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

[openstack-dev] [Heat] [Horizon] Heat Resource Topology Demo

[Tim Schnell]

Hey everyone,

Just a quick demo of the Resource Topology. I'm working on getting it into Code 
Review for Horizon either today or tomorrow.
http://www.youtube.com/watch?v=pe9EM8WhLPA

Thanks!
[cid:F8A7CDE7-7AE1-42CB-A834-D228A925FF7A]
<>___
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 Resource Topology Demo

[Tim Schnell]

Hey Steve,

Thanks, I have been trying to figure out the best place to put it and I agree, 
I'll add it to the Details tab. For now I just pushed it up as a tab in the 
dashboard but I'll move it.
https://review.openstack.org/#/c/36351/

[cid:BF160E9B-446E-48E5-AF4E-1A91CE1F2B75]

From: Steve Baker mailto:sba...@redhat.com>>
Reply-To: OpenStack Development Mailing List 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, July 9, 2013 4:39 PM
To: 
"openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Heat] [Horizon] Heat Resource Topology Demo

On 07/10/2013 04:59 AM, Tim Schnell wrote:
Just a quick demo of the Resource Topology. I'm working on getting it into Code 
Review for Horizon either today or tomorrow.
http://www.youtube.com/watch?v=pe9EM8WhLPA


Very nice, looking forward to this in Horizon.

I've seen Tim mention that this would go into its own tab on the stack page.  
Personally I'd like to see it at the top of the stack Details tab, making the 
Details tab more of a dashboard for the running stack.

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

Re: [openstack-dev] [Horizon] Navigation UX Enhancements - Collecting Issues

[Tim Schnell]

Most of my navigation related issues can be summed up into 3 problems.

  1.  Not having a secondary level of navigation in the left-nav really 
restricts the level of granularity that can be achieved through the navigation. 
Having an accordion-like nav structure would help this as well as setting a 
corresponding url convention like we have for the current nav (I.e. The url 
should be "dashboard/primary_nav/secondary_nav")
  2.  Which leads to my second issue, having a robust breadcrumb system so it 
is easy for the user to backtrack to previous pages would really help the user 
from getting lost in drill downs. A strong url convention would make this 
fairly easy to implement.
  3.  The fixed width of the left nav makes it awkward to have more than 3 
dashboards. Instead of the current tab-like structure for adding dashboard we 
could switch to a drop down.

Thanks for working on this Jarda!

[cid:2D3BAC12-0F3F-43C1-A5CC-C6F28BABB8C4]

From: Jaromir Coufal mailto:jcou...@redhat.com>>
Reply-To: OpenStack Development Mailing List 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, July 9, 2013 7:37 AM
To: OpenStack Development Mailing List 
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [Horizon] Navigation UX Enhancements - Collecting 
Issues

Hi everybody,

in UX community group on G+ popped out a need for enhancing user experience of 
main navigation, because there are spreading out various issues .

There is already created a BP for this: 
https://blueprints.launchpad.net/horizon/+spec/navigation-enhancement

Toshi had great idea to start discussion about navigation issues on mailing 
list.

So I'd like to ask all of you, if you have some issues with navigation, what 
are the issues you are dealing with? I'd like to gather as much feedback as 
possible, so we can design the best solution which covers most of the cases. 
Issues will be listed in BP and I will try to come out with design proposals 
which hopefully will help all of you.

Examples are following:
* Navigation is not scaling for more dashboards (Project, Admin, ...)
* Each dashboard might contain different hierarchy (number of levels)

What problems do you experience with navigation?

Thanks all for contributing
-- Jarda
<>___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Horizon] Navigation UX Enhancements - Collecting Issues

[Tim Schnell]

Hey Liz,

I briefly brought up horizontal navigation in the IRC meeting last week. I 
agree, first of all, that Left Nav will run into scaling issues at some point 
but I think Gabriel Hurley made a good point in that doing something as drastic 
as getting rid of the Left Nav and replacing it with Horizontal navigation in 
H3 may not be a good idea.

I would vote to see mockups for both, but maybe with the intention of releasing 
an upgraded Left Nav for Havana and working on something more drastic for 
Icehouse. I agree from a design perspective that horizontal nav is much more 
versatile and should probably be the end goal at some point in the future.

Thanks,
[cid:F5E8B380-1584-4DC7-8AC9-16ABE05DD765]

From: Liz Blanchard mailto:lsure...@redhat.com>>
Reply-To: OpenStack Development Mailing List 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, July 30, 2013 10:43 AM
To: OpenStack Development Mailing List 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Horizon] Navigation UX Enhancements - Collecting 
Issues


On Jul 19, 2013, at 3:34 AM, Jaromir Coufal 
mailto:jcou...@redhat.com>> wrote:

Hi Jeff,

thanks for contribution. As long as there is no more input in gathering issues, 
I'll try to wrap all the problems up in BP's whiteboard and we can start 
designing proposals.

Best
-- Jarda

Hi Jarda,

Thanks for taking this blueprint on! I'm happy to help out in the design space 
as well as it continues to move forward.

One thing I've been a bit concerned about is the left hand navigation. 
Left-handed navigation takes up a fair amount of prime working real-estate and 
the user would gain a lot of primary work space if this were moved to the top 
of the page and horizontally placed. Also, I think that having horizontal 
navigation would make it much easier as we continue to design for more than 1 
level. It feels like the left-hand navigation doesn't scale very well when it 
acts like the primary navigation. There is an article that was written by Louis 
Lazaris in 2010 that I think is a really good read when it comes to this 
discussion:
http://www.smashingmagazine.com/2010/01/11/the-case-against-vertical-navigation/

I'm definitely interested in what others think on this topic!

Thanks again,
Liz


On 2013/09/07 16:09, Walls, Jeffrey Joel (HP Converged Cloud - Cloud OS) wrote:
One issue I have is that the panels are physically grouped and it’s very 
difficult to logically re-group them.  For example, the Project dashboard 
explicitly lists the panel groups and the order of those panel groups.  Within 
each panel group, the individual panels are also explicitly listed.  What I 
would like to do is arrange the panels more logically without affecting the 
physical structure of the files or the order in the panel specification.

You could think of “Deployment” as a “section” under the Project dashboard tab. 
 In this “section”, I’d want to see things related to the actual deployment of 
virtual machines (e.g., Instances, Snapshots, Networks, Routers, etc).  I was 
beginning to tackle this in our code base and was planning to use some sort of 
accordion-type widget.  My thinking was that there would be “a few” (probably 
no more than 4) “sections” under the Project tab.  Each “section” would have 
elements within it that logically mapped to that section.

I think this is a great discussion and I’m very interested to hear where others 
are headed with their thinking, so thank you for getting it started!

Jeff

From: Jaromir Coufal [mailto:jcou...@redhat.com]
Sent: Tuesday, July 09, 2013 6:38 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [Horizon] Navigation UX Enhancements - Collecting 
Issues

Hi everybody,

in UX community group on G+ popped out a need for enhancing user experience of 
main navigation, because there are spreading out various issues .

There is already created a BP for this: 
https://blueprints.launchpad.net/horizon/+spec/navigation-enhancement

Toshi had great idea to start discussion about navigation issues on mailing 
list.

So I'd like to ask all of you, if you have some issues with navigation, what 
are the issues you are dealing with? I'd like to gather as much feedback as 
possible, so we can design the best solution which covers most of the cases. 
Issues will be listed in BP and I will try to come out with design proposals 
which hopefully will help all of you.

Examples are following:
* Navigation is not scaling for more dashboards (Project, Admin, ...)
* Each dashboard might contain different hierarchy (number of levels)

What problems do you experience with navigation?

Thanks all for contributing
-- Jarda



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

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.