[openstack-dev] [heat] [cinder backend options] Propagate Cinder backend config information to Heat

Pradip Mukhopadhyay pradip.interra at gmail.com
Fri Nov 28 16:57:19 UTC 2014


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 <
pshchelokovskyy at 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 <tengqim at 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 at lists.openstack.org
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141128/726d1f5a/attachment.html>


More information about the OpenStack-dev mailing list