Open Stack

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150105/04d759e3/attachment.html>