<div dir="ltr">That's true. Heat's job is mainly to call other OpenStack APIs in correct order in order to achieve desired combination of infrastructure resources. Physically though it may run on a completely different host where these files are not present, even including a host that is outside of the datacenter where OpenStack is deployed (so called Heat standalone mode). The only info Heat knows about other OpenStack services is what Heat can get trough their API.</div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr">Pavlo Shchelokovskyy<div>Software Engineer</div><div>Mirantis Inc</div><div><a href="http://www.mirantis.com" target="_blank">www.mirantis.com</a></div></div></div></div>
<br><div class="gmail_quote">On Fri, Nov 28, 2014 at 3:15 PM, Qiming Teng <span dir="ltr"><<a href="mailto:tengqim@linux.vnet.ibm.com" target="_blank">tengqim@linux.vnet.ibm.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The first thing you may want to check is the Cinder API.  If I'm<br>
understanding this correctly, Heat only interact with other OpenStack<br>
services via their APIs.  It is not supposed to peek into their<br>
internals.<br>
<br>
Regards,<br>
  - Qiming<br>
<div><div class="h5"><br>
On Fri, Nov 28, 2014 at 06:19:56PM +0530, Pradip Mukhopadhyay wrote:<br>
> Hello,<br>
><br>
><br>
> Suppose we have a cinder backend in local.conf | cinder.conf as :<br>
><br>
><br>
> [myNFSBackend]<br>
> nfs_mount_options = nfsvers=3<br>
> volume_backend_name = myNFSBackend<br>
> volume_driver = cinder.volume.drivers.netapp.common.NetAppDriver<br>
> netapp_server_hostname = IP<br>
> netapp_server_port = 80<br>
> netapp_storage_protocol = nfs<br>
> netapp_storage_family = ontap_cluster<br>
> netapp_login = admin<br>
> netapp_password = password<br>
> netapp_vserver = vserver_name<br>
> nfs_shares_config = /opt/stack/nfs.shares<br>
><br>
><br>
> We would like to access some of such cinder backend configuration<br>
> information from Heat. More specifically from custom resource inside the<br>
> Heat (e.g. access the netapp_server_hostname, netapp_login, netapp_password<br>
> etc. when defining a custom resource class extending the base Resource<br>
> class). The purpose is to facilitate some (soap) service call to the<br>
> backend storage from custom resource definitions.<br>
><br>
><br>
> What is the best pattern/mechanism available? Any pointers to code/doc will<br>
> be highly appreciated.<br>
><br>
><br>
> Does any database table holds the local.conf (or service specific conf)<br>
> information?<br>
><br>
><br>
><br>
> Thanks,<br>
> Pradip<br>
<br>
</div></div>> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div>