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 <cbky...@gmail.com
<mailto:cbky...@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
<alev...@cloudscaling.com <mailto:alev...@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
<alev...@cloudscaling.com <mailto:alev...@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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
