Open Stack

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

-- 
Sean Dague
http://dague.net