Re: [openstack-dev] [heat] [cinder backend options] Propagate Cinder backend config information to Heat
Cinder does not expose an API for this, and should not be doing so - such an API is a security risk and of little benefit to most deployments in doing so. On 28 November 2014 at 18:57, Pradip Mukhopadhyay wrote: > 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 >> 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 > > -- Duncan Thomas ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] [cinder backend options] Propagate Cinder backend config information to Heat
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 > 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
Re: [openstack-dev] [heat] [cinder backend options] Propagate Cinder backend config information to Heat
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 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
Re: [openstack-dev] [heat] [cinder backend options] Propagate Cinder backend config information to Heat
One option would be to use a secret management service like Barbican[1] to store those credentials/secrets and use it whenever you want to make a SOAP API call. There's also Barbican resources available in the contrib section of the Heat repository which could also possibly be used and referenced to your custom resource's properties. [1] https://wiki.openstack.org/wiki/Barbican Regards, Sirushti Murugesan From: Qiming Teng [teng...@linux.vnet.ibm.com] Sent: Friday, November 28, 2014 6:45 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [heat] [cinder backend options] Propagate Cinder backend config information to Heat 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
Re: [openstack-dev] [heat] [cinder backend options] Propagate Cinder backend config information to Heat
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] [heat] [cinder backend options] Propagate Cinder backend config information to Heat
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
