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:


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

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>>:


    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:


    The spec should give some context to what we are trying to do with


    So in your specific case just some comments:

    - No change necessary to the v2 code

    - 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

    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


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

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



        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']:
                    if attr == 'name':
                        key = "OS-EXT-SRV-ATTR:instance_%s" % attr
                        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.


        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.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Reply via email to