Ask Your Question
0

Heat Resource Modelling

asked 2016-07-25 13:23:31 -0500

dmunro gravatar image

I have recently begun looking at building or finding a set of tools that would allow me to build Heat Orchestration Templates by starting off looking at a list of known Heat Resources. It was easy enough to find OS HOT Builder blueprints and even a Rackspace backed project to build a builder (excuse the wording). What I'm looking for here is to better understand why Heat Resources seem to be so loosely defined - without any real model being enforced/encoded into the resource definition.

Take OS::Neutron::Subnet and OS::Neutron::Net resources as an example. Subnet is defined with a 'NETWORK' property that identifies an Openstack network by ID :

...
NETWORK: properties.Schema(
        properties.Schema.STRING,
        _('The ID of the attached network.'),
        required=False,
        constraints=[
            constraints.CustomConstraint('neutron.network')
        ],
    )
...

As much as the specified 'neutron.network' CustomConstraint will at ensure the network actually exists there is nothing here that explicitly infers any kind of model or relationships actually exist. Why is this? Am I completely out to lunch to think that it would be handy to be able to look at a OS::Neutron::Subnet resource definition and be able to see that the Network requirement could be met by taking the ID from a OS::Neutron::Net resource.

My ignorance is on the table and Nomex suit is on ... thanks for any insight you might provide.

edit retag flag offensive close merge delete

1 answer

Sort by ยป oldest newest most voted
0

answered 2016-07-28 07:44:57 -0500

zaneb gravatar image

Am I completely out to lunch to think that it would be handy to be able to look at a OS::Neutron::Subnet resource definition and be able to see that the Network requirement could be met by taking the ID from a OS::Neutron::Net resource.

No, that's not crazy. Maintaining a two-way linking between which types of resources can supply properties of other resources would be an insane amount of effort for very little benefit though (and it can cause problems of its own). However in the future we hope to start annotating resources and their attributes with the same custom constraint types that we use on properties (and parameters). The goal is improved pre-flight validation, but the same data would be useful for external template building tools. You're welcome to contribute to this effort.

edit flag offensive delete link more

Comments

Thanks for the response Zane.

I am with you with regards to the potential trouble with having to maintain mappings, or perhaps more specifically, with maintaining the models that could be used to help drive/support orchestration. Hopefully these challenges just keep things interesting.

dmunro gravatar imagedmunro ( 2016-08-04 12:00:13 -0500 )edit

FWIW, my current focus is on modelling relationships. I like that you mentioned annotations as I am headed in that path as well with the thought that I'll let TOSCA concepts influence the design. If I find my efforts get anywhere I will definitely be interested in contributing.

dmunro gravatar imagedmunro ( 2016-08-04 12:04:55 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Get to know Ask OpenStack

Resources for moderators

Question Tools

1 follower

Stats

Asked: 2016-07-25 13:23:31 -0500

Seen: 198 times

Last updated: Jul 28 '16