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
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
