Open Stack

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.

Best regards,
   Alex Levine

On 2/16/15 12:45 PM, Alex Xu wrote:
>
>
> 2015-02-16 9:47 GMT+08:00 Christopher Yeoh <cbkyeoh at gmail.com 
> <mailto:cbkyeoh at gmail.com>>:
>
>     Hi,
>
>     Am happy for this to be continued on openstack-dev as long as no
>     one disagrees (maybe the next person can just CC it there?
>
>     So as was pointed out on the review there is some early
>     documentation (we're still working on v2.1 specific doco as well
>     as expanding on the microversion docs) on microversions in-tree:
>
>     http://docs.openstack.org/developer/nova/devref/api_microversions.html
>
>     The spec should give some context to what we are trying to do with
>     microversions:
>
>     http://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/api-microversions.html
>
>     So in your specific case just some comments:
>
>     - No change necessary to the v2 code
>     (nova/api/openstack/compute/contriib
>
>     - Will need to modify the v2.1
>     (nova/api/openstack/compute/plugins/v3) code
>       - Need to ensure that when run with the users requesting v2.1
>     that it still acts like v2
>       - Given what is in the queue at the moment I'm guessing yours
>     will probably end up being v2.4 at least
>
>     - unittests for v2 and v2.1/v2.1 microversions have mostly been
>     merged to reduce code overhead.
>       - You can see that the tests are able to handle talking to
>     either v2 (old code) or v2.1 (new code) or v2.1 with
>     microversions.
>
>     This https://review.openstack.org/#/c/140313/ is a good example of
>     that and is likely to be the first microversioned code to merge
>
>     - We need to keep api samples for each interface where the version
>     changes. The above review shows that and as Alex mentioned
>     depends on https://review.openstack.org/155233 (currently -2'd but
>     that is only due to some confusion over whether the microversion
>     spec was approved for Kilo or not (it was).
>
>     There are a few ways to implement different behaviour for
>     microversioning, for your specific use I'd recommend:
>
>     in _extend_server get it to take an extra parameter
>     version_request and in detail/show get them to pass
>     req.api_version_request
>
>     replacing:
>
>         for attr in ['host', 'name', 'reservation_id', 'launch_index',30
>                          'hostname', 'kernel_id', 'ramdisk_id',31
>                          'root_device_name', 'user_data']:
>
>     with something like:
>
>     attrs_to_use = ['host', 'name']
>
>     if (version_requested >= api_version_request.APIVersionRequest("2.4")"
>         attrs_to_use.extends(array_of_new_stuff)
>
>
>
> I think we support api_version decorator, see 
> https://review.openstack.org/141983
> But we need add decorator in the servers' index/detail and also in 
> this extend method.
>
>
>
>       for attr in ['host', 'name']:
>           blah blah blah
>
>     I think thats likely to be the simplest way to do it.
>
>
>
>
>     On Mon, Feb 16, 2015 at 7:19 AM, Alexandre Levine
>     <alevine at cloudscaling.com <mailto:alevine at cloudscaling.com>> wrote:
>
>         Thanks a lot, Alex.
>
>         I thought about this admin-only access problem.
>         What do you think if I change the policy.json so that this
>         extensions is not for admins only anymore and change
>         extended_server_attributes.py code like this:
>
>         class ExtendedServerAttributesController(wsgi.Controller):
>             def _extend_server(self, context, server, instance):
>                 if context.is_admin:
>                     key = "OS-EXT-SRV-ATTR:hypervisor_hostname"
>                     server[key] = instance['node']
>
>
>     So we're really trying to get away from hard coding any policy
>     because it can
>     make life harder for both deployers (can't change a policy without
>     editing code) and developers (they may
>     be unaware that something at a lower layer is preventing something
>     from work because of auth)
>
>     Perhaps a new policy that surpresses just the ones that you don't
>     want displayed would be an alternative?
>     Needs to be very well documented in the changelong though so
>     deployers understand what they may need
>     to change when upgrading.
>
>
> Agree with Chris, we shouldn't hard coding any policy. How about we 
> can add those attributes into os-extended-status that is for normal user.
>
>
>     Anyway am happy to continue the discussion via email/irc. What
>     timezone are you in? We also have a weekly irc
>     meeting Friday UTC0000 or I'm happy to help out on openstack-nova
>     if you ping me (cyeoh). Generally around work
>     hours for GMT+10:30
>
>     Regards,
>
>     Chris
>
>         for attr in ['host', 'name', 'reservation_id', 'launch_index',
>                              'hostname', 'kernel_id', 'ramdisk_id',
>                              'root_device_name', 'user_data']:
>                     if not context.is_admin and attr in ['host', 'name']:
>                         continue
>                     if attr == 'name':
>                         key = "OS-EXT-SRV-ATTR:instance_%s" % attr
>                     else:
>                         key = "OS-EXT-SRV-ATTR:%s" % attr
>                     server[key] = instance[attr]
>
>         Would that be a legit way to resolve the problem? (I protected
>         the original admin-only attributes with checking for
>         context.is_admin, and the rest is available for everybody)
>
>         Best regards,
>           Alex Levine
>
>
>
>         On 2/15/15 6:18 AM, Alex Xu wrote:
>>         Hi, Alexandre,
>>
>>         I commented on your patch and nova-specs for some comments
>>         and how to bump micro-version. Hope that helpful.
>>
>>         Thanks
>>         Alex
>>
>>         2015-02-14 15:46 GMT+08:00 Alexandre Levine
>>         <alevine at cloudscaling.com <mailto:alevine at cloudscaling.com>>:
>>
>>             Ok, thanks. Sitting tight, waiting for the API guys.
>>
>>             Best regards,
>>               Alex Levine
>>
>>
>>             On 2/14/15 2:15 AM, Dan Smith wrote:
>>
>>                     Can we do this on openstack-dev instead of
>>                     private email? It will also
>>                     hopefully keep other interested parties in the loop.
>>
>>                 I copied the API guys into the review initially, but
>>                 I think Alexandre
>>                 was looking for clarification if there was anything
>>                 else he needed to
>>                 do. I was just letting him know that I think he's in
>>                 fine shape for the
>>                 moment. I don't think -dev needs to be copied for
>>                 that, unless you want
>>                 to poll for comments, but that's not what he was asking.
>>
>>                 --Dan
>>
>>
>>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150217/87e1cd61/attachment.html>