Thanks for the tips Stan.
> it is stored exactly as it comes from Heat. In theory conversion to
> string could happen on Heat side, but most likely it just the output
> of reporter made it look like this
Did some digging and it actually seems to be a string on heat's end.
python-cinderclient seems to present volume attachment info as a list:
"""
from cinderclient.v2 import Client
...
for i in cinder.volumes.list():
print(type(i.attachments))
<type 'list'>
"""
whereas printing the value of outputs from python-heatclient gives:
"""
from heatclient.client import Client
...
s = heat.stacks.get('murano--sjsbdj0xwhrkz2')
pp = pprint.PrettyPrinter(indent=4)
pp.pprint(s.outputs)
[ { u'description': u'No description given',
u'output_key':
u'vol-08aea08f-f553-4f71-b839-bf4637516eaf-attachments',
u'output_value': u"[{u'server_id':
u'0f5731c1-da17-4209-a2ef-270c7056f9a3', u'attachment_id': u'88
1a5cea-be9e-4335-ad37-a24d09b36911', u'attached_at':
u'2017-03-31T14:05:26.000000', u'host_name': None, u'
volume_id': u'6c97f825-32e9-4369-8580-a4a576e67612', u'device':
u'/dev/vda', u'id': u'6c97f825-32e9-4369-8
580-a4a576e67612'}]"},
<snip>
u'output_key': u'addresses--ae9a638e712d450a87492ed792025a97',
u'output_value': [ { u'OS-EXT-IPS-MAC:mac_addr':
u'fa:16:3e:f6:26:ab',
u'OS-EXT-IPS:type': u'fixed',
u'addr': u'10.0.61.12',
u'port':
u'7967a4de-ccc1-49ec-a35c-f4d515e6cc96',
u'version': 4}]},
<snip>
"""
(note the value for 'addresses--ae9a638e712d450a87492ed792025a97' is in
the correct format)
Changing the schema type of this in heat from STRING to LIST fails to
validate[0], so somewhere between cinder and heat this is not getting
deserialised properly.
Anyhow, I think the issue has moved beyond the scope of MuranoPL, so I'm
just sending this more as a follow up for anyone who happens to be reading.
Thanks again for pointing me in the right direction.
-Paul
[0]
https://github.com/openstack/heat/blob/master/heat/engine/resources/openstack/cinder/volume.py#L222-L225
On 30/03/17 19:55, Stan Lagun wrote:
Hi Paul,
Here both key and value appear to be a string (note, I can't confirm this as
the typeinfo function doesn't appear to be available in Instance.yaml for some
reason... perhaps I'm using it wrong)
They are not strings. Reporter converts everything that is passed to it
into string by doing unicode(obj). What you see is the Python string
representation of lists and dicts, where every unicode string is
prefixed with "u".
Typinfo function works on objects (instances of MuranoPL classes), not
on primitive types like strings, dicts and lists.
1) Why is the content of this 'get_attr' coming from heat being stored in the
stack outputs as a string,
it is stored exactly as it comes from Heat. In theory conversion to
string could happen on Heat side, but most likely it just the output of
reporter made it look like this
2) Is there a way I can cast this to a list of dicts or similar
structure so it can be iterated as expected?
It's hard to answer without seeing your code and how you got the results
that you provided.
when I access this from a sample app, I end up with a list of strings,
shown by $reporter as: ...
Curly braces in the output indicate that this is not a list of strings
but rather the single dict converted to a string by reporter. So what
you see is the value of
that 'vol-7c8ee61f-a444-46a1-ad70-fc6fce6a7b56-attachments' output,
which sounds like what you're wanted it to be. In MuranoPL you can have
very detailed contracts: not just [] (any list) but something like
Contract:
- key1: string().notNull()
key2: int().notNull()
which is a list of dicts with contract on each dict entry. If you don't
get contract violation exception, you can be sure that the list contains
list of dicts with appropriate keys/values rather than list of strings
or anything else
Sincerely yours,
Stan Lagun
Principal Software Engineer @ Mirantis
<mailto:sla...@mirantis.com>
On Thu, Mar 30, 2017 at 10:17 AM, Paul Bourke <paul.bou...@oracle.com
<mailto:paul.bou...@oracle.com>> wrote:
Hi Stan,
I had a quick(hopefully) question about MuranoPL that I hope you
might be able to help with, Felipe had mentioned you are very
knowledgeable in this area. If you don't have time please disregard!
I'm working on a patch for the Murano core library to make volume
attachment info available, which is available at
https://review.openstack.org/451909
<https://review.openstack.org/451909>. It's mostly working, but I'm
having some issues getting the types correct in MuranoPL to make
this info consumable by end users.
The attachment info from a sample run in the stack $outputs looks
like this (taken from the dashboard using $reporter)
u'vol-7c8ee61f-a444-46a1-ad70-fc6fce6a7b56-attachments':
u"[{u'server_id': u'2891067b-e7bb-4ab9-a759-9e81096c0682',
u'attachment_id': u'7456a4b0-3abd-48a0-a0cb-f3fa0f2706bb',
u'attached_at': u'2017-03-30T16:51:57.000000', u'host_name': None,
u'volume_id': u'373e4a5a-46b6-4091-82d6-b3dba62d552b', u'device':
u'/dev/vda', u'id': u'373e4a5a-46b6-4091-82d6-b3dba62d552b'}]"
Here both key and value appear to be a string (note, I can't confirm
this as the typeinfo function doesn't appear to be available in
Instance.yaml for some reason... perhaps I'm using it wrong)
My goal is to then set this into a property of CinderVolume.yaml,
with a Contract of '[]'. However, when I access this from a sample
app, I end up with a list of strings, shown by $reporter as:
(u"[{u'server_id': u'2891067b-e7bb-4ab9-a759-9e81096c0682',
u'attachment_id': u'f5bd50ab-4040-4e2b-8b50-790781d9bc37',
u'attached_at': u'2017-03-30T16:51:59.000000', u'host_name': None,
u'volume_id': u'ed7eb535-9e81-4c97-b063-86936d4ee306', u'device':
u'/dev/vdb', u'id': u'ed7eb535-9e81-4c97-b063-86936d4ee306'}]",)
So my question is:
1) Why is the content of this 'get_attr' coming from heat being
stored in the stack outputs as a string, and
2) Is there a way I can cast this to a list of dicts or similar
structure so it can be iterated as expected?
Any tips much appreciated.
Thanks,
-Paul
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
