[openstack-dev] [Sahara] [Heat] validating properties of Sahara resources in Heat
msm at redhat.com
Wed Jan 7 22:03:59 UTC 2015
i'm not sure i can answer all these questions but i'll give it my best
shot and hopefully others will chime in =)
On 01/05/2015 08:17 AM, Pavlo Shchelokovskyy wrote:
> 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?
i don't think so. these are configured through the conf file associated
with the controller(s) and i don't think we expose an endpoint for
> - What would be the result of providing floating_ip_pool when Sahara is
> indeed configured with netns/proxy?
i think it will accept the floating_ip_pool values during cluster creation.
> Is it going to function normally, having just wasted several floating
> IPs from quota?
if sahara is configured for netns/proxy then it should use that method
for accessing the nodes. that being said, i think if you provide
floating ip pools then those will get sent along to the provisioning
engine, so it may waste the IPs.
this is a case where we could probably check for these values and either
produce an error or sanitize them. i'll have to test this in a live
> - And more crucial, what would happen if Sahara is _not_ configured to
> use netns/proxy and not provided with floating_ip_pool?
if sahara is configured to _not_ use netns/proxy, but _is_ configured
for floating pool then you will get an error for not providing the
floating pool id.
> Can that lead to cluster being created (at least VMs for it spawned)
> but Sahara would not be able to access them for configuration?
i don't think so. i think you will get an error when creating the
cluster(not the template).
> Would Sahara in that case kill the cluster/shutdown VMs or hang in
> some cluster failed state?
i don't think it would get that far, you should see an error when
creating the cluster.
> 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?
in this case, i think the new value will override the original value in
> - what would happen if I set this property (pass it via saharaclient)
> when Nova-network is in use?
i might need a little clarification on this question. but, if you have
sahara configured to _not_ use neutron and you supply a
neutron_management_network during cluster template creation, then i
think sahara will record the network but it won't actually try to
connect over that network.
this may be another area where we could produce an error if the network
> - what if I _do not_ pass this property and Neutron has several networks
i think this will result in an error during the cluster creation. i know
sahara will produce an error in this case, i'm just unsure as to when it
will be generated.
> 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.
i totally agree with the "fail-fast" approach, and in general i think
that sahara will attempt to follow that. in the cases you have described
above i think the most likely fail conditions will be when attempting
cluster creation. but, i don't think that the provisioning engine will
be called unless we can validate these networks.
hopefully this helps,
More information about the OpenStack-dev