Thanks Qiming & Pavlo. We had looked into the v2 of Cinder API listings: http://developer.openstack.org/api-ref-blockstorage-v2.html. However most likely (or may be we missed to note) none of the APIs peeped into/exposed the Cinder's backend configuration (the info we were looking for). So we were curious if, *by design, *it is not expected to expose that through Cinder? Or Cinder API can potentially be written to bridge the gap.
@Sirushti- that's interesting. Shall peep into it. Thanks. Pradip On Fri, Nov 28, 2014 at 7:46 PM, Pavlo Shchelokovskyy < pshchelokovs...@mirantis.com> wrote: > 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. > > Pavlo Shchelokovskyy > Software Engineer > Mirantis Inc > www.mirantis.com > > On Fri, Nov 28, 2014 at 3:15 PM, Qiming Teng <teng...@linux.vnet.ibm.com> > wrote: > >> The first thing you may want to check is the Cinder API. If I'm >> understanding this correctly, Heat only interact with other OpenStack >> services via their APIs. It is not supposed to peek into their >> internals. >> >> Regards, >> - Qiming >> >> On Fri, Nov 28, 2014 at 06:19:56PM +0530, Pradip Mukhopadhyay wrote: >> > Hello, >> > >> > >> > Suppose we have a cinder backend in local.conf | cinder.conf as : >> > >> > >> > [myNFSBackend] >> > nfs_mount_options = nfsvers=3 >> > volume_backend_name = myNFSBackend >> > volume_driver = cinder.volume.drivers.netapp.common.NetAppDriver >> > netapp_server_hostname = IP >> > netapp_server_port = 80 >> > netapp_storage_protocol = nfs >> > netapp_storage_family = ontap_cluster >> > netapp_login = admin >> > netapp_password = password >> > netapp_vserver = vserver_name >> > nfs_shares_config = /opt/stack/nfs.shares >> > >> > >> > We would like to access some of such cinder backend configuration >> > information from Heat. More specifically from custom resource inside the >> > Heat (e.g. access the netapp_server_hostname, netapp_login, >> netapp_password >> > etc. when defining a custom resource class extending the base Resource >> > class). The purpose is to facilitate some (soap) service call to the >> > backend storage from custom resource definitions. >> > >> > >> > What is the best pattern/mechanism available? Any pointers to code/doc >> will >> > be highly appreciated. >> > >> > >> > Does any database table holds the local.conf (or service specific conf) >> > information? >> > >> > >> > >> > Thanks, >> > Pradip >> >> > _______________________________________________ >> > 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 >> > > > _______________________________________________ > 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