Open Stack

hi Pavlo,

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

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 
querying them.

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

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

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

in this case, i think the new value will override the original value in 
the template.

> - 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 
is supplied.

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

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,
mike