<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 14, 2014 at 6:09 PM, Doug Hellmann <span dir="ltr"><<a href="mailto:doug.hellmann@dreamhost.com" target="_blank">doug.hellmann@dreamhost.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="h5">On Mon, Jan 13, 2014 at 9:36 PM, Jamie Lennox <span dir="ltr"><<a href="mailto:jamielennox@redhat.com" target="_blank">jamielennox@redhat.com</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>On Mon, 2014-01-13 at 10:05 -0500, Doug Hellmann wrote:<br>
> What requirement(s) led to keystone supporting this feature?<br>
<br>
</div></div>I've got no idea where the requirement came from however it is something that is<br>
supported now and so not something we can back out of.<br></blockquote><div><br></div></div></div><div><div style="font-size:small">If it's truly a requirement, we can look into how to make that work. The data is obviously present in the request, so we would just need to preserve it.</div>

</div></div></div></div></blockquote></div><br>
</div><div class="gmail_extra">We've seen a use case for arbitrary attributes in Keystone objects. Cloud administrator might want to store some metadata along with a user object. For example, customer name/id and couple additional fields for contact information. The same might be applied to projects and  domains.</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">So this is a very nice feature that should be kept around. It might be wrapped in some way (like in explicit unchecked "metadata" attribute) in a new API version though.</div>

</div>