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

As you can see we just need to expose some more info which is already
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

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)
- 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
- 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)
- 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)
- 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)
- 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)
- 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.


OpenStack Development Mailing List (not for usage questions)

Reply via email to