Comment 2 for bug 1504646

For backwards compatibility, I don't think deprecating will be enough.
For encryption keys (like used by Nova/Cinder volume encryption), I can have:

[stack@localhost devstack]$ openstack secret get http://10.30.118.79:9311/v1/secrets/bc924dfb-1bae-4657-a91e-49f451809976
+---------------+--------------------------------------------------------------------------+
| Field | Value |
+---------------+--------------------------------------------------------------------------+
| Secret href | http://10.30.118.79:9311/v1/secrets/bc924dfb-1bae-4657-a91e-49f451809976 |
| Name | Cinder Volume Key |
| Created | 2015-12-03 04:29:04+00:00 |
| Status | ACTIVE |
| Content types | {u'default': u'application/octet-stream'} |
| Algorithm | AES |
| Bit length | 256 |
| Secret type | symmetric |
| Mode | CBC |
| Expiration | None |
+---------------+--------------------------------------------------------------------------+

To get the payload in table format, I get this error:

[stack@localhost devstack]$ openstack secret get -p --payload_content_type 'application/octet-stream' http://10.30.118.79:9311/v1/secrets/bc924dfb-1bae-4657-a91e-49f451809976
'utf8' codec can't decode byte 0x9f in position 0: invalid start byte

If I add "-f value", I can see the payload:

[stack@localhost devstack]$ openstack secret get -p --payload_content_type 'application/octet-stream' -f value http://10.30.118.79:9311/v1/secrets/bc924dfb-1bae-4657-a91e-49f451809976
��]s�v���Ͳ<1ʔ���iu�5��+o_B�

I can decode it manually:

[stack@localhost devstack]$ openstack secret get -p --payload_content_type 'application/octet-stream' -f value http://10.30.118.79:9311/v1/secrets/bc924dfb-1bae-4657-a91e-49f451809976 | od -x
0000000 c69f 735d 7688 e08c cdf2 3cb2 ca31 aa94
0000020 b10f 698d 1c05 ad75 9b35 2b9c 5f6f 8f42
0000040 000a
0000041

At least for secrets with built-in secret types, Barbican client can be smarter about formatting.