Open Stack

All,

I have updated and reworked the review with the proposed microversions 
changes. Please take a look.
Hope tomorrow during the nova meeting we'll decide something about it.

Best regards,
   Alex Levine

On 2/17/15 5:54 PM, Sean Dague wrote:
> On 02/17/2015 09:38 AM, Alexandre Levine wrote:
>> I started this thread to get a couple of pointers from Dan Smith and
>> Sean Dague but it turned out to be a bigger discussion than I expected.
>>
>> So the history is, we're trying to add a few properties to be reported
>> for instances in order to cut workaround access to novaDB from the
>> standalone EC2 API project implementation. Previous nova meeting it was
>> discussed that there is still potentially a chance to get this done for
>> Kilo providing the changes are not risky and not complex. The changes
>> really are not complex and not risky, you can see it in this prototype
>> review:
>>
>> https://review.openstack.org/#/c/155853/
>>
>> As you can see we just need to expose some more info which is already
>> available.
>> Two problems have arisen:
>>
>> 1. I should correctly pack it into this new mechanism of microversions
>> and Cristopher Yeoh and Alex Xu are very helpful in this area.
>>
>> 2. The os-extended-server-attributes extension is actually admin-only
>> accessible.
>>
>> And this second problem produced several options some of which are based
>> on Alex Xu's suggestions.
>>
>> 1. Stay with the admin-only access. (this is the easiest one)
>> Problems:
>> - Standalone EC2 API will have to use admin context to get this info (it
>> already has creds configured for its metadata service anyways, so no big
>> deal).
>> - Some of the data potentially can be usable for regular users (this can
>> be addressed later by specific policies configurations mechanism as
>> suggested by Alex Xu).
>>
>> 2. Allow new properties to be user-available, the existing ones will
>> stay admin-only (extension for the previous one)
>> Problems:
>> - The obvious way is to check for context.is_admin for existing options
>> while allowing the extension to be user-available in policy.json. It
>> leads to hardcode of this behavior and is not recommended. (see previous
>> thread for details on that)
>>
>> 3. Put new properties in some non-admin extensions, like
>> os-extended-status. (almost as easy as the first one)
>> Problems:
>> - They just don't fit in there. Status is about statuses, not about some
>> static or dynamic properties of the object.
>>
>> 4. Create new extension for this. (more complicated)
>> Problems:
>> - To start with I couldn't come up with the naming for it. Because
>> existing os-extended-server-attributes is such and obvious choice for
>> this. Having os-extended-attributes, or os-extended-instance-attributes,
>> or os-server-attributes besides would be very confusing for both users
>> and future developers.
>>
>> 5. Put it into different extensions - reservation_id and launch_index
>> into os-multiple-create, root_device_name into os_extended_volumes, ....
>> (most complicated)
>> Problems:
>> - Not all of the ready extensions exist. There is no ready place to put
>> hostname, ramdisk_id, kernel_id. We'd still have to create a new extension.
>>
>> I personally tend to go for 1. It's easiest and fastest at the moment to
>> put everything in admin-only access and since nova API guys consider
>> allowing fine-tuning of policies for individual properties, it'll be
>> possible later to make some of it available for users. Or if necessary
>> it'll be possible to just switch off admin restriction altogether for
>> this extension. I don't think hypervisor_name, host and instance_name
>> are such a secret info that it should be hidden from users.
>>
>> Please let me know what you think.
> Option 1 seems fine for now, I feel like we can decide on different
> approaches in Liberty, but getting a microversion adding this as admin
> only seems fine.
>
> 	-Sean
>