Answers inlined and marked as [AL]. On Mon, Jan 5, 2015 at 5:17 AM, Pavlo Shchelokovskyy < pshchelokovs...@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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev