Hi all, I would like to ask Sahara developers' opinion on two bugs raised against Heat's resources - [1] and [2]. 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.
In Heat's Sahara-specific resources we have such properties as floating_ip_pool for OS::Sahara::NodeGroupTemplate [4] and neutron_management_network for both OS::Sahara::ClusterTemplate [5] and OS::Sahara::Cluster [6]. My questions are about when and under which conditions those properties are required to successfully start a Sahara Cluster. floating_ip_pool: I was pointed that Sahara could be configured to use netns/proxy to access the cluster VMs instead of floating IPs. My questions are: - Can that particular configuration setting (netns/proxy) be assessed via saharaclient? - What would be the result of providing floating_ip_pool when Sahara is indeed configured with netns/proxy? Is it going to function normally, having just wasted several floating IPs from quota? - And more crucial, what would happen if Sahara is _not_ configured to use netns/proxy and not provided with floating_ip_pool? Can that lead to cluster being created (at least VMs for it spawned) but Sahara would not be able to access them for configuration? Would Sahara in that case kill the cluster/shutdown VMs or hang in some cluster failed state? neutron_management_network: I understand the point that it is redundant to use it in both resources (although we are stuck with deprecation period as those are part of Juno release already). Still, my questions are: - would this property passed during creation of Cluster override the one passed during creation of Cluster Template? - what would happen if I set this property (pass it via saharaclient) when Nova-network is in use? - what if I _do not_ pass this property and Neutron has several networks available? The reason I'm asking is that in Heat we try to follow "fail-fast" approach, especially for billable resources, to avoid situation when a (potentially huge) stack is being created and breaks on last or second-to-last resource, leaving user with many resources spawned (even if for a short time if the stack rollback is enabled) which might cost a hefty sum of money for nothing. That is why we are trying to validate the template as thoroughly as we can before starting to create any actual resources in the cloud. Thus I'm interested in finding the best possible (or least-worse) cover-it-all strategy for validating properties being set for these resources. [1] https://bugs.launchpad.net/heat/+bug/1399469 [2] https://bugs.launchpad.net/heat/+bug/1402844 [3] https://review.openstack.org/#/c/141310 [4] https://github.com/openstack/heat/blob/master/heat/engine/resources/sahara_templates.py#L136 [5] https://github.com/openstack/heat/blob/master/heat/engine/resources/sahara_templates.py#L274 [6] https://github.com/openstack/heat/blob/master/heat/engine/resources/sahara_cluster.py#L79 Best regards, Pavlo Shchelokovskyy Software Engineer Mirantis Inc www.mirantis.com
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
