<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hello,<br>
<br>
seems too big to do the inline comments, so just a few notes here:<br>
<br>
If we truly want to have Templates portable, it would mean to have
the 'metadata' somehow standardised, right?<br>
Otherwise if every UI will add their own metadata, then I hardly
see the templates as portable. I think first step would be then to
delete<br>
the metadata and add your own, unless you are fine to have 80% of
the template some metadata you don't use. That also won't<br>
help the readability. What will help a readability are the verbose
comments.<br>
<br>
I am not really sure how long it can take to add new specialized
tags, that are used only in Horizon and are well documented. I
think showing<br>
this, should get the patch merged very quickly. That seems to me
like a portable solution. <br>
<br>
IMO for the template catalogue we would probably need a new
service, something like Glance, so that's probably a more distant
future. <br>
<br>
For the use-cases:<br>
-----------------------<br>
<br>
ad 1) <br>
Something more general next to Description may be more useful,
like keywords, packages or components.<br>
Example:<br>
<br>
Description...<br>
Keywords: wordpress, mysql...<br>
<br>
Or you could parse it from e.g. packages (though that is not
always used, so being able to write it explicitly might be handy)<br>
<br>
ad 2)<br>
Maybe adding something like 'author' tag may be a good idea,
though you can find all the history in git repo,<br>
given you use
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<a href="https://github.com/openstack/heat-templates">https://github.com/openstack/heat-templates</a>
. If you have different repo, <span class="p-Indicator"
style="color: rgb(51, 51, 51); font-family: Consolas,
'Liberation Mono', Courier, monospace; font-size:
11.818181991577148px; font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal; line-height:
17.99715805053711px; orphans: auto; text-align: start;
text-indent: 0px; text-transform: none; white-space: pre;
widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;
background-color: rgb(255, 255, 255);"></span>adding something
like<br>
Origin: <a href="https://github.com/openstack/heat-templates">https://github.com/openstack/heat-templates</a>
maybe?<br>
<br>
ad 3)<br>
So having a fix and documented schema seems to be a good way to be
portable, at least to me. I am not <br>
against UI only tags inside the template, that are really useful
for everybody. We will find out by collectively <br>
reviewing that, which usually brings some easier solution. <br>
<br>
Or you don't think, it will get too wild to have some 'metadata'
section completely ignored by Heat? Seems <br>
to me like there will be a lot of cases, when people won't push
their template to upstream, because of the <br>
metadata they have added to their templates, that nobody else will
ever use. Is somebody else concerned<br>
about this?<br>
<br>
That's my 2 cents.<br>
<br>
Kind regards,<br>
Ladislav<br>
<br>
<br>
On 11/26/2013 07:32 AM, Keith Bray wrote:<br>
</div>
<blockquote cite="mid:CEB99B28.8DEE6%25keith.bray@rackspace.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<div>Thanks Steve. I appreciate your input. I have added the use
cases for all to review:</div>
<div><a moz-do-not-send="true"
href="https://wiki.openstack.org/wiki/Heat/StackMetadata">https://wiki.openstack.org/wiki/Heat/StackMetadata</a></div>
<div><br>
</div>
<div>What are next steps to drive this to resolution? </div>
<div><br>
</div>
<div>Kind regards,</div>
<div>-Keith</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:11pt;
text-align:left; color:black; BORDER-BOTTOM: medium none;
BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT:
0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid;
BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span>Steve Baker <<a
moz-do-not-send="true" href="mailto:sbaker@redhat.com">sbaker@redhat.com</a>><br>
<span style="font-weight:bold">Reply-To: </span>"OpenStack
Development Mailing List (not for usage questions)" <<a
moz-do-not-send="true"
href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Date: </span>Monday, November
25, 2013 11:47 PM<br>
<span style="font-weight:bold">To: </span>"<a
moz-do-not-send="true"
href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>"
<<a moz-do-not-send="true"
href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Subject: </span>Re:
[openstack-dev] [heat][horizon]Heat UI related requirements
& roadmap<br>
</div>
<div><br>
</div>
<div>
<div bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 11/26/2013 03:26 PM, Keith
Bray wrote:<br>
</div>
<blockquote
cite="mid:CEB949D1.8DDE4%25keith.bray@rackspace.com"
type="cite">
<pre wrap="">On 11/25/13 5:46 PM, "Clint Byrum" <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:clint@fewbar.com"><clint@fewbar.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Excerpts from Tim Schnell's message of 2013-11-25 14:51:39 -0800:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">Wiggle room is indeed provided. But reviewers need to understand your
motivations, which is usually what blueprints are used for. If you're
getting push back, it is likely because your blueprints to not make the
use cases and long term vision obvious.
</pre>
</blockquote>
<pre wrap="">Clint, can you be more specific on what is not clear about the use case?
What I am seeing is that the use case of meta data is not what is being
contested, but that the Blueprint of where meta data should go is being
contested by only a few (but not all) of the core devs. The Blueprint for
in-template metadata was already approved for Icehouse, but now that work
has been delivered on the implementation of that blueprint, the blueprint
itself is being contested:
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://blueprints.launchpad.net/heat/+spec/namespace-stack-metadata">https://blueprints.launchpad.net/heat/+spec/namespace-stack-metadata</a>
I'd like to propose that the blueprint that has been accepted go forth
with the code that exactly implements it, and if there are alternative
proposals and appropriate reasons for the community to come to consensus
on a different approach, that we then iterate and move the data (deprecate
the older feature if necessary, e.g. If that decision comes after
Icehouse, else of a different/better implementation comes before Icehouse,
then no harm done).
</pre>
</blockquote>
I don't think the Heat project has ever set any expectations
over what it means for a blueprint to be Approved. Given
that the PTL can approve blueprints (that's me =) but anyone
in heat-core can legitimately -2 any review, I don't think
it is realistic to expect Approved to mean anything other
than "something that is worthy of starting to work on". Nova
has adopted a policy of only approving blueprints will full
specifications. That would avoid situations like this but
I'd like to avoid that until Heat is more mature and that
kind of process is really necessary.<br>
<br>
How a blueprint is progressed after approval depends
entirely on the feature and the people involved. This could
be one of:<br>
1) Implement it already, its trivial!<br>
2) Write enough of a specification to convince enough core
developers that it has value<br>
3) Have list, irc and summit discussions for some amount of
time, then do 2) or 1)<br>
<br>
In this case 1) has proven to be not enough, so I would
recommend 2). I don't think this will come to 3) but we seem
to be well on the way ;)<br>
<br>
I've linked this blank wiki page to the blueprint so a spec
containing use cases can go there.<br>
<blockquote
cite="mid:CEB949D1.8DDE4%25keith.bray@rackspace.com"
type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">Nobody has said you can't have meta-data on stacks, which is what other
projects use.
</pre>
<blockquote type="cite">
<pre wrap="">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
</pre>
</blockquote>
<pre wrap="">Interesting. Would you support adding a "category" keyword to python so
we don't have to put it in setup.cfg and so that the egg format doesn't
need that section? Pypi can just parse the python to categorize the apps
when they're uploaded. We could also have a file on disk for qcow2 images
that we upload to glance that will define the meta-data.
To be more direct, I don't think the templates themselves are where this
meta-data belongs. A template is self-aware by definition, it doesn't
need the global metadata section to tell it that it is WordPress. For
anything else that needs to be globally referenced there are parameters.
Having less defined inside the template means that you get _more_ wiggle
room for your template repository.
</pre>
</blockquote>
<pre wrap="">Clint, you are correct that the Template does not need to know what it is.
It's every other service (and users of those services) that a Template
passes through or to that would care to know what it is. We are suggesting
we put that meta data in the template file and expressly ignore it for
purposes of parsing the template language in the Heat engine, so we agree
it not a necessary part of the template. Sure, we could encode the
metadata info in a separate catalog... but, take the template out of the
catalog and now all that useful associated data is lost or would need to
be recreated by someone or some service. That does not make the template
portable, and that is a key aspect of what we are trying to achieve (all
user-facing clients, like Horizon, or humans reading the file, can take
advantage). We don't entirely know yet what is most useful in portability
and what isn't, so meta data in-template provides the "wiggle room"
innovation space to suss that out. We already know of some specific use
cases of data that we feel are important, which Tim identified one
specific example.. As specific metadata items become popular or prove to
be useful to rely on by the larger community or service operators (public
and private) of Heat, we as a community can drive that information back
into the schema for the template or some portable format mechanism.
</pre>
<blockquote type="cite">
<pre wrap="">I 100% support having a template catalog. IMO it should be glance,
which is our catalog service in OpenStack. Who cares if nova or heat are
consuming images or templates. It is just sharable blobs of data and
meta-data in a highly scalable service. It already has the concept of
global and tenant-scope. It just needs an image type of 'hot' and then
heat can start consuming templates from glance. And the template authors
should maintain some packaging meta-data in glance to communicate to
users that this is "Wordpress" and "Single-Node". If Glance's meta-data
is too limiting, expand it! I'm sure image authors and consumers would
appreciate that.
</pre>
</blockquote>
<pre wrap="">This is definitely interesting... And takes the long view IMO. Let me
explain: I don't anticipate Heat catalog'ing in Glance is something that
has a high chance of getting implemented in the Icehouse timeframe (at
least, not more so than in-template metadata), do you? From a SOA service
deployer perspective, I'm sure you can appreciate that rolling out new
functionality in Glance to support an Orchestration project use case is
not simple, and requires strong business justification and coordination as
an operator of a cloud.. One worth exploring for sure, but not the go-to
default strategy. I view the metadata change as very minor with little to
no disruption to any service, including Heat (Heat just ignores the
metadata, completely).. This fits very well in an iterative development
model. New blueprints could be raised, as you suggested, to move metadata
and catalog features into Glance. My concern is that if we go the Glance
route now, we are encouraging a precedent that we aren't iterative (due to
abandoning an already accepted blueprint in favor of a more complex and
time intensive solution) and that we won't get this implemented within the
current release cycle.
</pre>
</blockquote>
Hrm, glance is for large binary data and has a metadata
model only for OS images - the overlap with the needs of a
template catalog don't seem very obvious to me.<br>
<blockquote
cite="mid:CEB949D1.8DDE4%25keith.bray@rackspace.com"
type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">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...
</pre>
</blockquote>
<pre wrap="">That is all api stuff, not language stuff.
</pre>
</blockquote>
<pre wrap="">If this were done solely at the API, it would have to be maintained 1-to-1
with a template (in which case there is an implicit and explicit
association), and exported with the template in order to port the
template.
</pre>
</blockquote>
Good point, this is the sort of requirement that can be
detailed in <a moz-do-not-send="true"
href="https://wiki.openstack.org/wiki/Heat/StackMetadata">
https://wiki.openstack.org/wiki/Heat/StackMetadata</a>
<blockquote
cite="mid:CEB949D1.8DDE4%25keith.bray@rackspace.com"
type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">Your example puts the template catalog in front of this feature, and I
think that exposes this feature as misguided.
</pre>
</blockquote>
<pre wrap="">I'd like template author and creation date portable so that it goes
wherever the template goes in a portable format that consumers (any
client) of the Heat service can understand. I'd also like this
information to be available for a deployed stack in Heat, so it is need
not be catalog specific. If author/creation-date information were only
available in the catalog, then we would have to entirely wrap the Heat API
in another service or risk drift in the data between Heat and the separate
non-wrapping catalog service. Instead of raising a blueprint for every
piece of data that may be useful to deploying this service (some of which
certain folks may not care about [e.g. Many of the folks arguing against
metadata all together], the in-template metadata is, IMO, a suitable
approach to experiment and then we can drive back experiential use-cases
into future improvements (e.g. in-language schema changes or catalog
changes). At Rackspace we have experience running a nearly identical
service, so we know this data, in this particular place, is a valid use
case for consumers of an Orchestration service.
Example:
(1) Cloud customer of service operator deploys a template (may or may not
have come from the catalog)
(2) Customer encounters problem with the stack and calls support
(3) Support specialist [not the service operator/developer] is trying to
figure out who to contact for additional help given failures seen with the
stack. The dev team of the service is not the expert in application foo
and did not develop the template. It's not a Heat issue, it's a
template/application foo issue.
Having this detail come from Glance, as you pointed out, would be great.
But, my hope is that many folks will develop and share templates, and the
folks developing templates won't necessarily be running glance or have
access to upload their own images into glance (that is a service operator
choice). If we force this basic info to glance, we are limiting our
portability (and therefore adoption story) of Heat.
-Keith
</pre>
</blockquote>
All good and valid use cases, lets get them clearly
communicated in the spec.<br>
<br>
</div>
</div>
</span>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
OpenStack-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>