Open Stack

Hi Ruslan,

I did not intend to suggest that definition of things like billing rules
should necessarily be supported syntax in Heat. Murano is certainly able
to develop whatever features it would like, including an alternative DSL.
I have a preference towards minimizing DSLs across the OpenStack
ecosystem, if possible. I hope that helps clear up my position.  If the
goal is to specify pertinent information that a billing system could
consume, I default back to wanting to specify/store that information as
associated data in the catalog with the application definition (e.g. HOT
artifact in Glance).  If the billing/rules logic crosses multiple HOT
artifacts, I find that very interesting and would enjoy reading about a
specific use-case.

As for Trove and Savanna, I view these as application "Services."
Service registry/discovery isn't what I thought Murano was aiming to be,
but I've been wrong about what Murano is/isn't/wants-to-be many times
before, so my apologies if I'm misunderstanding again. I am a bit more
confused now, however, given that discovery/definition of exposed software
services is entering the conversation?

Thank you for considering my comments,
-Keith

On 3/18/14 7:32 PM, "Ruslan Kamaldinov" <rkamaldinov at mirantis.com> wrote:

>- definition of an application which is already exposed via REST API.
>Think of
>  something like Sahara (ex. Savanna) or Trove developed in-house for
>internal
>  company needs. app publishers wouldn't be happy if they'll be forced to
>  develop a new resource for Heat
>- definition of billing rules for an application