[openstack-dev] [Heat] HOT Software configuration proposal

Thomas Spatzier thomas.spatzier at de.ibm.com
Tue Oct 22 16:35:57 UTC 2013


Zane Bitter <zbitter at redhat.com> wrote on 22.10.2013 17:23:52:
> From: Zane Bitter <zbitter at redhat.com>
> To: openstack-dev at lists.openstack.org,
> Date: 22.10.2013 17:26
> Subject: Re: [openstack-dev] [Heat] HOT Software configuration proposal
>
> On 22/10/13 16:35, Thomas Spatzier wrote:
> > Zane Bitter <zbitter at redhat.com> wrote on 22.10.2013 15:24:28:
> >> From: Zane Bitter <zbitter at redhat.com>
> >> To: openstack-dev at lists.openstack.org,
> >> Date: 22.10.2013 15:27
> >> Subject: Re: [openstack-dev] [Heat] HOT Software configuration
proposal
> >>
> >> On 22/10/13 09:15, Thomas Spatzier wrote:
> >>> BTW, the convention of properties being input and attributes being
> > output,
> >>> i.e. that subtle distinction between properties and attributes is not
> >>> really intuitive, at least not to me as non-native speaker, because I
> > used
> >>> to use both words as synonyms.
> >>
> >> As a native speaker, I can confidently state that it's not intuitive
to
> >> anyone ;)
> >
> > Phew, good to read that ;-)
> >
> >>
> >> We unfortunately inherited these names from the Properties section and
> >> the Fn::GetAtt function in cfn templates. It's even worse than that,
> >> because there's a whole category of... uh... things (DependsOn,
> >> DeletionPolicy, &c.) that don't even have a name - I always have to
> >> resist the urge to call them 'attributes' too.
> >
> > So is this something we should try to get straight in HOT while we
still
> > have the flexibility?
>
> Y-yes. Provided that we can do it without making things *more*
> confusing, +1. That's hard though, because there are a number of places
> we have to refer to them, all with different audiences:
>   - HOT users
>   - cfn users
>   - Existing developers
>   - New developers
>   - Plugin developers
>
> and using different names for the same thing can cause problems. My test
> for this is: if you were helping a user on IRC debug an issue, is there
> a high chance you would spend 15 minutes talking past each other because
> they misunderstand the terminology?

Hm, good point. Seems like it would really cause more confusion than it
helps. So back away from the general idea of renaming things that exist
both in cfn and HOT.
What we should try of course is to give new concepts that will only exist
in HOT intuitive names.

>
> > Regarding properties/attributes for example, to me I would call both
just
> > properties of a resource or component, and then I can write them or
read
> > them like:
> >
> > components:
> >    my_component:
> >      type: ...
> >      properties:
> >        my_prop: { get_property: [ other_component,
other_component_prop ] }
> >
> >    other_component:
> >      # ...
> >
> > I.e. you write property 'my_prop' of 'my_component' in its properties
> > section, and you read property 'other_component_prop' of
'other_component'
> > using the get_property function.
> > ... we can also call them attributes, but use one name, not two
different
> > names for the same thing.
>
> IMO inputs (Properties) and outputs (Fn::GetAtt) are different things
> (and they exist in different namespaces), so -1 for giving them the same
> name.
>
> In an ideal world I'd like HOT to use something like get_output_data (or
> maybe just get_data), but OTOH we have e.g. FnGetAtt() and
> attributes_schema baked in to the plugin API that we can't really
> change, so it seems likely to lead to developers and users adopting
> different terminology, or making things very difficult for new
> developers, or both :(
>
> cheers,
> Zane.
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>




More information about the OpenStack-dev mailing list