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

Steven Hardy shardy at redhat.com
Tue Nov 26 15:27:39 UTC 2013


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Steve



More information about the OpenStack-dev mailing list