[openstack-dev] [heat][horizon]Heat UI related requirements & roadmap
clint at fewbar.com
Wed Nov 27 06:50:21 UTC 2013
Excerpts from Ladislav Smola's message of 2013-11-26 06:04:12 -0800:
> seems too big to do the inline comments, so just a few notes here:
> If we truly want to have Templates portable, it would mean to have the
> 'metadata' somehow standardised, right?
Can you point to another portable application distribution system where
meta-data about the applications has been standardized in the language
itself? Can you give us data on how successful that is?
I can point to plenty where the meta-data is specified outside the
application itself, because it makes sense that these are two different
> Otherwise if every UI will add their own metadata, then I hardly see the
> templates as portable. I think first step would be then to delete
> the metadata and add your own, unless you are fine to have 80% of the
> template some metadata you don't use. That also won't
> help the readability. What will help a readability are the verbose comments.
Actually that is just the thing. Keeping them portable means making them
useful in different deployments without changing them. Deployments are
not all going to want to organize things by the same set of tags.
Consider a private cloud used for deploying IT apps internally. They may
want to tag SugarCRM as 'sales' and OpenERP as 'manufacturing'. These
are separate concerns, so they should not be in the same template.
What _would_ be useful would be curation of those packaged Heat apps
into a generally useful "default" repository for Heat deployers to take
advantage of. A pypi for Heat, if you will. That would help to
homogenize things and prevent wasteful forking of the most generic
templates. But the decisions of those curators should not be set in
stone for all deployers.
> I am not really sure how long it can take to add new specialized tags,
> that are used only in Horizon and are well documented. I think showing
> this, should get the patch merged very quickly. That seems to me like a
> portable solution.
> IMO for the template catalogue we would probably need a new service,
> something like Glance, so that's probably a more distant future.
Why not just use glance? Where is this belief coming from that Glance
would be hard to add what is basically a single image type to? I
understand SOA and we need to separate things. But "registry of blobs
of data" has a service.
If people want to expose a user-uploadable HOT glance but not
a user-uploadable image glance, then have two endpoints, and two
glances. But don't write a whole new piece of software just because
modifying an existing one seems hard.
> For the use-cases:
> ad 1)
> Something more general next to Description may be more useful, like
> keywords, packages or components.
> Keywords: wordpress, mysql...
> Or you could parse it from e.g. packages (though that is not always
> used, so being able to write it explicitly might be handy)
If you take out the catalog though, this has no place in the template.
> ad 2)
> Maybe adding something like 'author' tag may be a good idea, though you
> can find all the history in git repo,
> given you use https://github.com/openstack/heat-templates . If you have
> different repo, adding something like
> Origin: https://github.com/openstack/heat-templates maybe?
Both of those things work great if you make git repo+meta-data file the
Things like Origin: get out of date really fast in my experience because
they are informational and not actually important to the use of the
> ad 3)
> So having a fix and documented schema seems to be a good way to be
> portable, at least to me. I am not
> against UI only tags inside the template, that are really useful for
> everybody. We will find out by collectively
> reviewing that, which usually brings some easier solution.
UI only tags are awesome, and I like them a lot.
> Or you don't think, it will get too wild to have some 'metadata' section
> completely ignored by Heat? Seems
> to me like there will be a lot of cases, when people won't push their
> template to upstream, because of the
> metadata they have added to their templates, that nobody else will ever
> use. Is somebody else concerned
> about this?
I actually think such a section will be abused heavily to have different
templates per deployment. Keeping this stuff out of the template means
deployers who need to arrange things differently can consume the
template without modifying it.
More information about the OpenStack-dev