Stan Lagun <sla...@mirantis.com> wrote on 22.10.2013 19:02:38:
> From: Stan Lagun <sla...@mirantis.com>
> To: OpenStack Development Mailing List
<openstack-dev@lists.openstack.org>,
> Date: 22.10.2013 19:06
> Subject: Re: [openstack-dev] [Heat] HOT Software configuration proposal
>
> Hello,
> I've been reading through the thread and the wiki pages and I'm
> still confused by the terms. Is there a clear definition of what do
> we understand by component from user's and developer's point of
> view. If I write "component, type:MySQL" what is behind that
> definition? I mean how does the system know what exactly MySQL is
I think the current proposal is not that Heat would support very specific
component types (like MySQL, Apache, Tomcat etc.) but component is more of
a generic construct to represent a piece of software. The type attribute of
a component then just calls out the config management tool (e.g. Chef) to
install and configure that piece of software. By pointing a component to,
say, a Chef cookbook for setting up MySQL the runtime type would be MySQL.
That is at least my view on this.
I agree, however, that it needs to be straightened out how the term
"component" is really used.
> and how to install it? What MySQL version is it gonna be? Will it be
> x86 or x64? How does the system understand that I need MySQL for
> Windows on Windows VM rather then Linux MySQL? What do I as a
> developer need to do so that it would be possible to have "type:
> MyCoolComponentType"?
>
> On Tue, Oct 22, 2013 at 8:35 PM, Thomas Spatzier
<thomas.spatz...@de.ibm.com
> > wrote:
> Zane Bitter <zbit...@redhat.com> wrote on 22.10.2013 17:23:52:
> > From: Zane Bitter <zbit...@redhat.com>
> > To: openstack-dev@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 <zbit...@redhat.com> wrote on 22.10.2013 15:24:28:
> > >> From: Zane Bitter <zbit...@redhat.com>
> > >> To: openstack-dev@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@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> --
> Sincerely yours
> Stanislav (Stan) Lagun
> Senior Developer
> Mirantis
> 35b/3, Vorontsovskaya St.
> Moscow, Russia
> Skype: stanlagun
> www.mirantis.com
> slagun@mirantis.com_______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
