<div dir="ltr">Hi Thomas,<div><br></div><div>I agree with you on semantics part. At the same time I see a potential question which might appear - if semantics is limited by few states visible for Heat engine, then who actually does software orchestration? </div>
<div>Will it be reasonable then to have software orchestration as separate subproject for Heat as a part of "Orchestration" OpenStack program? Heat engine will then do dependency tracking and will use components as a reference for software orchestration engine which will perform actual deployment and high level software components coordination.</div>
<div><br></div><div>This separated software orchestration engine may address all specific requirements proposed by different teams in this thread without affecting existing Heat engine.</div><div><br></div><div>Thanks</div>
<div>Georgy</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Oct 22, 2013 at 12:06 PM, Thomas Spatzier <span dir="ltr"><<a href="mailto:thomas.spatzier@de.ibm.com" target="_blank">thomas.spatzier@de.ibm.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Georgy Okrokvertskhov <<a href="mailto:gokrokvertskhov@mirantis.com">gokrokvertskhov@mirantis.com</a>> wrote on 22.10.2013<br>
20:01:19:<br>
> From: Georgy Okrokvertskhov <<a href="mailto:gokrokvertskhov@mirantis.com">gokrokvertskhov@mirantis.com</a>><br>
<div class="im">> To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>>,<br>
</div>> Date: 22.10.2013 20:05<br>
<div class="im">> Subject: Re: [openstack-dev] [Heat] HOT Software configuration proposal<br>
><br>
</div><div class="im">> Hi,<br>
><br>
> I would agree with Stan that we need to discuss definitions before<br>
> going deeply to the implementation.<br>
><br>
> The first example on the <a href="https://wiki.openstack.org/wiki/Heat/" target="_blank">https://wiki.openstack.org/wiki/Heat/</a><br>
> Blueprints/hot-software-config shows components like install_mysql<br>
> and install_wordpress.<br>
<br>
</div>Good point. I also think that at least the examples currently used are more<br>
of an "automation step" than a "component".<br>
IMO component should represent some kind of software installation (e.g. a<br>
web server, a DBMS, etc.), where automation is used under the covers to<br>
<div class="im">install and configure that piece of software.<br>
</div>From an orchestration point of view, a reasonable semantics would be that<br>
when a component is in state CREATE_COMPLETE it is ready to use, e.g. a web<br>
server is ready to serve applications. With respect to the automation that<br>
was used to bring up the component, it would return successful (and this<br>
would be signaled to Heat) when the component setup is done.<br>
<br>
For example, the following could represent an Apache web server component,<br>
installed using Chef:<br>
<br>
components:<br>
apache:<br>
type: OS::Heat::SoftwareConfig_Chef<br>
cookbook: <a href="http://www.example.com/my_apache_cookbook.zip" target="_blank">http://www.example.com/my_apache_cookbook.zip</a><br>
properties:<br>
http_port: 8080<br>
<br>
'apache' is just a name here that indicates of course what you get. The<br>
type indicates that a component provide able to invoke Chef automation is<br>
used. The cookbook attribute points to the cookbook to use, which will<br>
install and configure apache. By setting the http_port property to 8080,<br>
you provide input to the Chef cookbook. The SoftwareConfig_Chef component<br>
provider will implement the logic to pass properties to the Chef invocation<br>
in the right syntax.<br>
<div><div class="h5"><br>
> I would say that this is a bit confusing because I expected to see<br>
> component definitions instead of software deployment definition<br>
> process. I think this is a quite dangerous path here because this<br>
> example shows us that we can use components as installation steps<br>
> definition instead of real component definition.<br>
> If one continue to do this approach and defines more and more<br>
> granular steps as a components they will come to workflow definition<br>
> composed in terms of components. This approach does not add either<br>
> simplicity or clarity in the HOT template.<br>
><br>
> Thanks<br>
> Georgy<br>
><br>
><br>
<br>
> On Tue, Oct 22, 2013 at 10:02 AM, Stan Lagun <<a href="mailto:slagun@mirantis.com">slagun@mirantis.com</a>> wrote:<br>
> Hello,<br>
<br>
> I've been reading through the thread and the wiki pages and I'm<br>
> still confused by the terms. Is there a clear definition of what do<br>
> we understand by component from user's and developer's point of<br>
> view. If I write "component, type:MySQL" what is behind that<br>
> definition? I mean how does the system know what exactly MySQL is<br>
> and how to install it? What MySQL version is it gonna be? Will it be<br>
> x86 or x64? How does the system understand that I need MySQL for<br>
> Windows on Windows VM rather then Linux MySQL? What do I as a<br>
> developer need to do so that it would be possible to have "type:<br>
> MyCoolComponentType"?<br>
><br>
<br>
> On Tue, Oct 22, 2013 at 8:35 PM, Thomas Spatzier<br>
<<a href="mailto:thomas.spatzier@de.ibm.com">thomas.spatzier@de.ibm.com</a><br>
> > wrote:<br>
> Zane Bitter <<a href="mailto:zbitter@redhat.com">zbitter@redhat.com</a>> wrote on 22.10.2013 17:23:52:<br>
> > From: Zane Bitter <<a href="mailto:zbitter@redhat.com">zbitter@redhat.com</a>><br>
> > To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>,<br>
> > Date: 22.10.2013 17:26<br>
> > Subject: Re: [openstack-dev] [Heat] HOT Software configuration proposal<br>
> ><br>
> > On 22/10/13 16:35, Thomas Spatzier wrote:<br>
> > > Zane Bitter <<a href="mailto:zbitter@redhat.com">zbitter@redhat.com</a>> wrote on 22.10.2013 15:24:28:<br>
> > >> From: Zane Bitter <<a href="mailto:zbitter@redhat.com">zbitter@redhat.com</a>><br>
> > >> To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>,<br>
> > >> Date: 22.10.2013 15:27<br>
> > >> Subject: Re: [openstack-dev] [Heat] HOT Software configuration<br>
> proposal<br>
> > >><br>
> > >> On 22/10/13 09:15, Thomas Spatzier wrote:<br>
> > >>> BTW, the convention of properties being input and attributes being<br>
> > > output,<br>
> > >>> i.e. that subtle distinction between properties and attributes is<br>
not<br>
> > >>> really intuitive, at least not to me as non-native speaker, because<br>
I<br>
> > > used<br>
> > >>> to use both words as synonyms.<br>
> > >><br>
> > >> As a native speaker, I can confidently state that it's not intuitive<br>
> to<br>
> > >> anyone ;)<br>
> > ><br>
> > > Phew, good to read that ;-)<br>
> > ><br>
> > >><br>
> > >> We unfortunately inherited these names from the Properties section<br>
and<br>
> > >> the Fn::GetAtt function in cfn templates. It's even worse than that,<br>
> > >> because there's a whole category of... uh... things (DependsOn,<br>
> > >> DeletionPolicy, &c.) that don't even have a name - I always have to<br>
> > >> resist the urge to call them 'attributes' too.<br>
> > ><br>
> > > So is this something we should try to get straight in HOT while we<br>
> still<br>
> > > have the flexibility?<br>
> ><br>
> > Y-yes. Provided that we can do it without making things *more*<br>
> > confusing, +1. That's hard though, because there are a number of places<br>
> > we have to refer to them, all with different audiences:<br>
> > - HOT users<br>
> > - cfn users<br>
> > - Existing developers<br>
> > - New developers<br>
> > - Plugin developers<br>
> ><br>
> > and using different names for the same thing can cause problems. My<br>
test<br>
> > for this is: if you were helping a user on IRC debug an issue, is there<br>
> > a high chance you would spend 15 minutes talking past each other<br>
because<br>
> > they misunderstand the terminology?<br>
<br>
> Hm, good point. Seems like it would really cause more confusion than it<br>
> helps. So back away from the general idea of renaming things that exist<br>
> both in cfn and HOT.<br>
> What we should try of course is to give new concepts that will only exist<br>
> in HOT intuitive names.<br>
><br>
> ><br>
> > > Regarding properties/attributes for example, to me I would call both<br>
> just<br>
> > > properties of a resource or component, and then I can write them or<br>
> read<br>
> > > them like:<br>
> > ><br>
> > > components:<br>
> > > my_component:<br>
> > > type: ...<br>
> > > properties:<br>
> > > my_prop: { get_property: [ other_component,<br>
> other_component_prop ] }<br>
> > ><br>
> > > other_component:<br>
> > > # ...<br>
> > ><br>
> > > I.e. you write property 'my_prop' of 'my_component' in its properties<br>
> > > section, and you read property 'other_component_prop' of<br>
> 'other_component'<br>
> > > using the get_property function.<br>
> > > ... we can also call them attributes, but use one name, not two<br>
> different<br>
> > > names for the same thing.<br>
> ><br>
> > IMO inputs (Properties) and outputs (Fn::GetAtt) are different things<br>
> > (and they exist in different namespaces), so -1 for giving them the<br>
same<br>
> > name.<br>
> ><br>
> > In an ideal world I'd like HOT to use something like get_output_data<br>
(or<br>
> > maybe just get_data), but OTOH we have e.g. FnGetAtt() and<br>
> > attributes_schema baked in to the plugin API that we can't really<br>
> > change, so it seems likely to lead to developers and users adopting<br>
> > different terminology, or making things very difficult for new<br>
> > developers, or both :(<br>
> ><br>
> > cheers,<br>
> > Zane.<br>
> ><br>
> > _______________________________________________<br>
> > OpenStack-dev mailing list<br>
> > <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> ><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
<br>
> --<br>
> Sincerely yours<br>
> Stanislav (Stan) Lagun<br>
> Senior Developer<br>
> Mirantis<br>
> 35b/3, Vorontsovskaya St.<br>
> Moscow, Russia<br>
> Skype: stanlagun<br>
> <a href="http://www.mirantis.com" target="_blank">www.mirantis.com</a><br>
> <a href="mailto:slagun@mirantis.com">slagun@mirantis.com</a><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
><br>
<br>
><br>
> --<br>
> Georgy Okrokvertskhov<br>
> Technical Program Manager,<br>
> Cloud and Infrastructure Services,<br>
> Mirantis<br>
> <a href="http://www.mirantis.com" target="_blank">http://www.mirantis.com</a><br>
> Tel. <a href="tel:%2B1%20650%20963%209828" value="+16509639828">+1 650 963 9828</a><br>
</div></div>> Mob. <a href="tel:%2B1%20650%20996%203284" value="+16509963284">+1 650 996 3284</a>_______________________________________________<br>
<div class="HOEnZb"><div class="h5">> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Georgy Okrokvertskhov<br>
Technical Program Manager,<br>Cloud and Infrastructure Services,<br>
Mirantis<br>
<a href="http://www.mirantis.com/" target="_blank">http://www.mirantis.com</a><br>
Tel. +1 650 963 9828<br>
Mob. +1 650 996 3284<br>
</div>