Open Stack

Answers inlined and marked as [AL].

On Mon, Jan 5, 2015 at 5:17 AM, Pavlo Shchelokovskyy <
pshchelokovskyy at mirantis.com> wrote:

> 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?
>

[AL] No, settings are configured in sahara.conf and hardly to be checked
outside of sahara.


> - 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?
>

[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.


> - 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?
>

[AL] Sahara will return validation error on attempt to create cluster. No
resources will be created.

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).
>

[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.


>
> Still, my questions are:
> - would this property passed during creation of Cluster override the one
> passed during creation of Cluster Template?
>

[AL] Yes, Sahara looks to template only when no value provided in cluster
request.


> - what would happen if I set this property (pass it via saharaclient) when
> Nova-network is in use?
>

[AL] Validation error will be returned


> - what if I _do not_ pass this property and Neutron has several networks
> available?
>

[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).


> 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150107/5dfe9cee/attachment.html>