Open Stack

Georgy Okrokvertskhov <gokrokvertskhov at mirantis.com> wrote on 22.10.2013
20:01:19:
> From: Georgy Okrokvertskhov <gokrokvertskhov at mirantis.com>
> To: OpenStack Development Mailing List
<openstack-dev at lists.openstack.org>,
> Date: 22.10.2013 20:05
> Subject: Re: [openstack-dev] [Heat] HOT Software configuration proposal
>
> Hi,
>
> I would agree with Stan that we need to discuss definitions before
> going deeply to the implementation.
>
> The first example on the https://wiki.openstack.org/wiki/Heat/
> Blueprints/hot-software-config shows components like install_mysql
> and install_wordpress.

Good point. I also think that at least the examples currently used are more
of an "automation step" than a "component".
IMO component should represent some kind of software installation (e.g. a
web server, a DBMS, etc.), where automation is used under the covers to
install and configure that piece of software.
>From an orchestration point of view, a reasonable semantics would be that
when a component is in state CREATE_COMPLETE it is ready to use, e.g. a web
server is ready to serve applications. With respect to the automation that
was used to bring up the component, it would return successful (and this
would be signaled to Heat) when the component setup is done.

For example, the following could represent an Apache web server component,
installed using Chef:

components:
  apache:
    type: OS::Heat::SoftwareConfig_Chef
    cookbook: http://www.example.com/my_apache_cookbook.zip
    properties:
      http_port: 8080

'apache' is just a name here that indicates of course what you get. The
type indicates that a component provide able to invoke Chef automation is
used. The cookbook attribute points to the cookbook to use, which will
install and configure apache. By setting the http_port property to 8080,
you provide input to the Chef cookbook. The SoftwareConfig_Chef component
provider will implement the logic to pass properties to the Chef invocation
in the right syntax.

> I would say that this is a bit confusing because I expected to see
> component definitions instead of software deployment definition
> process. I think this is a quite dangerous path here because this
> example shows us that we can use components as installation steps
> definition instead of real component definition.
> If one continue to do this approach and defines more and more
> granular steps as a components they will come to workflow definition
> composed in terms of components. This approach does not add either
> simplicity or clarity in the HOT template.
>
> Thanks
> Georgy
>
>

> On Tue, Oct 22, 2013 at 10:02 AM, Stan Lagun <slagun at mirantis.com> wrote:
> 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
> 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.spatzier at de.ibm.com
> > wrote:
> 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
> >
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at 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 at mirantis.com
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

>

>
> --
> Georgy Okrokvertskhov
> Technical Program Manager,
> Cloud and Infrastructure Services,
> Mirantis
> http://www.mirantis.com
> Tel. +1 650 963 9828
> Mob. +1 650 996 3284_______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev