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" <rkamaldi...@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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev