[openstack-dev] [Sahara] [Heat] validating properties of Sahara resources in Heat
alazarev at mirantis.com
Wed Jan 7 22:22:32 UTC 2015
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 -  and .
> Below I am going to repeat some of my comments from those bugs and
> associated Gerrit reviews  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 
> and neutron_management_network for both OS::Sahara::ClusterTemplate 
> and OS::Sahara::Cluster .
> My questions are about when and under which conditions those properties
> are required to successfully start a Sahara Cluster.
> 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
[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.
> 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
> 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
> - 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
[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.
>  https://bugs.launchpad.net/heat/+bug/1399469
>  https://bugs.launchpad.net/heat/+bug/1402844
>  https://review.openstack.org/#/c/141310
> Best regards,
> Pavlo Shchelokovskyy
> Software Engineer
> Mirantis Inc
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev