<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">I'd like to suggest that we take a step back and identify the actual requirement(s) we're trying address, independent of the actual implementation (current or otherwise).  Once that requirement is clearly stated, we can think of viable approaches and then, lastly, how the current architecture can be re-configured or modified to accommodate those approaches.  Right now this conversation has the feel of a nebulous requirement being addressed with a kludged approach.<div><br></div><div>-- Jon</div><div><br><div><div><div>On Nov 13, 2013, at 5:54 PM, Andrey Lazarev <<a href="mailto:alazarev@mirantis.com">alazarev@mirantis.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">John,<div><br></div><div>I think we should either select one of the listed border approaches (no validation or full validation) or define some strict rules on what is allowed and what is not. Otherwise phrases like "<font face="arial, sans-serif">at a minimum a cluster template would contain node groups" is a speculation and we will not be able to determine right way to solve them. I can easily suggest any number of concerns like listed above ("cluster template with tt without jt has no sense" , "cluster template should contain at least namenode", etc.). </font></div>
<div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">I like idea of no validation for template. If I want to save anti-affinity params in cluster template, but don't know which nodegroups will be used, why can't I do that?     </font> </div>
<div><div><br></div><div>Thanks,</div><div>Andrew.</div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Nov 13, 2013 at 12:23 PM, John Speidel <span dir="ltr"><<a href="mailto:jspeidel@hortonworks.com" target="_blank">jspeidel@hortonworks.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I strongly agree that we should try to keep templates as flexible as possible by allowing some values to be omitted and provided at a later time.  But, in this case, we are talking about cluster templates without any node groups being specified.  I think that at a minimum a cluster template would contain node groups but could omit the node group counts which could be provided at launch time.  This makes a lot of sense.  But, in my opinion, without at least specifying the set of node groups in a cluster template, configuration really wouldn't make sense and therefore the template would not be of much/any value.<br>

</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Nov 13, 2013 at 10:08 AM, Alexander Ignatov <span dir="ltr"><<a href="mailto:aignatov@mirantis.com" target="_blank">aignatov@mirantis.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>Hi, Andrew</div><div><br></div><div>Agreed with your opinion. Initially Savanna’s templates approach is the option 1 you are talking about. </div>

<div>This was designed at the start of Savanna 0.2 release cycle. It was also documented here: <a href="https://wiki.openstack.org/wiki/Savanna/Templates" target="_blank">https://wiki.openstack.org/wiki/Savanna/Templates</a> . </div>

<div>Maybe some points are outdated but the idea is the same as the option 1: user can create cluster template and don’t need to specify all fields, for example ’node_groups’ field. And these fields, both required and optional, can be overwritten in the cluster object even if it contains ‘cluster_template_id’.</div>

<div><br></div><div>I see you raised this question because of patch <a href="https://review.openstack.org/#/c/56060/" target="_blank">https://review.openstack.org/#/c/56060/</a>. I think it’s just a bug in the validation level not in api.</div>

<div><br></div><div>I also agree that we should change UI part accordingly, at least add an ability for users to override fields set in cluster and node group templates during the cluster creation.</div><br><div>
<div>Regards,</div><div>Alexander Ignatov</div><div><br></div><br>
</div>
<br><div><div><div>On 12 Nov 2013, at 23:20, Andrey Lazarev <<a href="mailto:alazarev@mirantis.com" target="_blank">alazarev@mirantis.com</a>> wrote:</div><br></div><blockquote type="cite"><div>
<div><div dir="ltr">Hi all,<div><br></div><div>I want to raise the question "What template is". Answer to this question could influence UI, validation and user experience significantly. I see two possible answers:</div>


<div><span style="font-family:'Arial Unicode MS',Arial,sans-serif">1. Template is a simplification for object creation. It allows to keep common params in one place and not specify them each time. </span></div>
<div><span style="font-family:'Arial Unicode MS',Arial,sans-serif">2. Template is a full description of object. User should be able to create object from template without specifying any params.</span></div>
<div><span style="font-family:'Arial Unicode MS',Arial,sans-serif"><br></span></div><div><span style="font-family:'Arial Unicode MS',Arial,sans-serif">As I see the current approach is the option 1, but UI is done mostly for option 2. This leads to situations when user creates incomplete template (backend allows it because of option 1), but can't use it later (UI doesn't allow to work with incomplete templates).</span></div>


<div><span style="font-family:'Arial Unicode MS',Arial,sans-serif"><br></span></div><div><font face="Arial Unicode MS, Arial, sans-serif">Let's define common vision on how will we treat templates and document this somehow.</font></div>


<div><font face="Arial Unicode MS, Arial, sans-serif"><br></font></div><div><font face="Arial Unicode MS, Arial, sans-serif">My opinion is that we should proceed with the option 1 and change UI accordingly.    </font></div>


<div><br></div><div>Thanks,</div><div>Andrew</div></div></div></div>
_______________________________________________<br>OpenStack-dev mailing list<br><a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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>

</blockquote></div><br></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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></blockquote></div><br></div>

<br>
<span style="color:rgb(128,128,128);font-family:Arial,sans-serif;font-size:10px">CONFIDENTIALITY NOTICE</span><br style="color:rgb(128,128,128);font-family:Arial,sans-serif;font-size:10px"><span style="color:rgb(128,128,128);font-family:Arial,sans-serif;font-size:10px">NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You.</span><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></blockquote></div><br></div>
_______________________________________________<br>OpenStack-dev mailing list<br><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br></blockquote></div><br></div></div></body></html>
<br>
<span style="color:rgb(128,128,128);font-family:Arial,sans-serif;font-size:10px">CONFIDENTIALITY NOTICE</span><br style="color:rgb(128,128,128);font-family:Arial,sans-serif;font-size:10px"><span style="color:rgb(128,128,128);font-family:Arial,sans-serif;font-size:10px">NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You.</span>