<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>- What would be the result of providing floating_ip_pool when Sahara is indeed configured with netns/proxy?<br>  Is it going to function normally, having just wasted several floating IPs from quota?<br>- 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><br>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><br>Still, my questions are:<br>- would this property passed during creation of Cluster override the one passed during creation of Cluster Template?<br>- what would happen if I set this property (pass it via saharaclient) when Nova-network is in use?<br>- what if I _do not_ pass this property and Neutron has several networks available?<br><br>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">https://bugs.launchpad.net/heat/+bug/1399469</a><br>[2] <a href="https://bugs.launchpad.net/heat/+bug/1402844">https://bugs.launchpad.net/heat/+bug/1402844</a><br>[3] <a href="https://review.openstack.org/#/c/141310">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">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">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">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 class="gmail_signature"><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>