<div dir="ltr">Answers inlined and marked as [AL].<br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 5, 2015 at 5:17 AM, Pavlo Shchelokovskyy <span dir="ltr"><<a href="mailto:pshchelokovskyy@mirantis.com" target="_blank">pshchelokovskyy@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Hi all,<br><br>I would like to ask Sahara developers' opinion on two bugs raised against Heat's resources - [1] and [2].<br>Below I am going to repeat some of my comments from those bugs and associated Gerrit reviews [3] to have the conversation condensed here in ML.<br><br>In Heat's Sahara-specific resources we have such properties as floating_ip_pool for OS::Sahara::NodeGroupTemplate [4]<br>and neutron_management_network for both OS::Sahara::ClusterTemplate [5] and OS::Sahara::Cluster [6].<br>My questions are about when and under which conditions those properties are required to successfully start a Sahara Cluster.<br><br>floating_ip_pool:<br><br>I was pointed that Sahara could be configured to use netns/proxy to access the cluster VMs instead of floating IPs.<br><br>My questions are:<br>- Can that particular configuration setting (netns/proxy) be assessed via saharaclient?<br></div></blockquote><div> </div><div>[AL] No, settings are configured in sahara.conf and hardly to be checked outside of sahara.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">- What would be the result of providing floating_ip_pool when Sahara is indeed configured with netns/proxy?<br></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">  Is it going to function normally, having just wasted several floating IPs from quota?<br></div></blockquote><div><br></div><div>[AL] It will assign floating IP as requested. Floating IP could be used not only for management by Sahara, but for other purposes too. User could request to assign floating IP.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">- And more crucial, what would happen if Sahara is _not_ configured to use netns/proxy and not provided with floating_ip_pool?<br>  Can that lead to cluster being created (at least VMs for it spawned) but Sahara would not be able to access them for configuration?<br>  Would Sahara in that case kill the cluster/shutdown VMs or hang in some cluster failed state?<br></div></blockquote><div><br></div><div>[AL] Sahara will return validation error on attempt to create cluster. No resources will be created.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">neutron_management_network:<br>I understand the point that it is redundant to use it in both resources<br>(although we are stuck with deprecation period as those are part of Juno release already).<br></div></blockquote><div><br></div><div>[AL] neutron_management_network must be specified somewhere in case of neutron. It could be either template OR cluster. No need to specify it in both places.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><br>Still, my questions are:<br>- would this property passed during creation of Cluster override the one passed during creation of Cluster Template?<br></div></blockquote><div> </div><div>[AL] Yes, Sahara looks to template only when no value provided in cluster request.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">- what would happen if I set this property (pass it via saharaclient) when Nova-network is in use?<br></div></blockquote><div><br></div><div>[AL] Validation error will be returned</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">- what if I _do not_ pass this property and Neutron has several networks available?<br></div></blockquote><div><br></div><div>[AL] Validation error will be returned even if only one neutron network available. Sahara currently doesn't support automatic network selection (could be a nice feature).</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">The reason I'm asking is that in Heat we try to follow "fail-fast" approach, especially for billable resources,<br>to avoid situation when a (potentially huge) stack is being created and breaks on last or second-to-last resource,<br>leaving user with many resources spawned (even if for a short time if the stack rollback is enabled)<br>which might cost a hefty sum of money for nothing. That is why we are trying to validate the template<br>as thoroughly as we can before starting to create any actual resources in the cloud.<br><br>Thus I'm interested in finding the best possible (or least-worse) cover-it-all strategy<br>for validating properties being set for these resources.<br><br>[1] <a href="https://bugs.launchpad.net/heat/+bug/1399469" target="_blank">https://bugs.launchpad.net/heat/+bug/1399469</a><br>[2] <a href="https://bugs.launchpad.net/heat/+bug/1402844" target="_blank">https://bugs.launchpad.net/heat/+bug/1402844</a><br>[3] <a href="https://review.openstack.org/#/c/141310" target="_blank">https://review.openstack.org/#/c/141310</a><br>[4] <a href="https://github.com/openstack/heat/blob/master/heat/engine/resources/sahara_templates.py#L136" target="_blank">https://github.com/openstack/heat/blob/master/heat/engine/resources/sahara_templates.py#L136</a><br>[5] <a href="https://github.com/openstack/heat/blob/master/heat/engine/resources/sahara_templates.py#L274" target="_blank">https://github.com/openstack/heat/blob/master/heat/engine/resources/sahara_templates.py#L274</a><br>[6] <a href="https://github.com/openstack/heat/blob/master/heat/engine/resources/sahara_cluster.py#L79" target="_blank">https://github.com/openstack/heat/blob/master/heat/engine/resources/sahara_cluster.py#L79</a><br><br>Best regards,<br><br clear="all"><div><div><div dir="ltr">Pavlo Shchelokovskyy<div>Software Engineer</div><div>Mirantis Inc</div><div><a href="http://www.mirantis.com" target="_blank">www.mirantis.com</a></div></div></div></div>
</div>
<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></div>