<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
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.<br>
<br>
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:<br>
<br>
<a class="moz-txt-link-freetext" href="https://review.openstack.org/#/c/155853/">https://review.openstack.org/#/c/155853/</a><br>
<br>
As you can see we just need to expose some more info which is
already available.<br>
Two problems have arisen:<br>
<br>
1. I should correctly pack it into this new mechanism of
microversions and Cristopher Yeoh and Alex Xu are very helpful in
this area.<br>
<br>
2. The os-extended-server-attributes extension is actually
admin-only accessible.<br>
<br>
And this second problem produced several options some of which are
based on Alex Xu's suggestions.<br>
<br>
1. Stay with the admin-only access. (this is the easiest one)<br>
Problems: <br>
- 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). <br>
- 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).<br>
<br>
2. Allow new properties to be user-available, the existing ones will
stay admin-only (extension for the previous one)<br>
Problems:<br>
- 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)<br>
<br>
3. Put new properties in some non-admin extensions, like
os-extended-status. (almost as easy as the first one)<br>
Problems:<br>
- They just don't fit in there. Status is about statuses, not about
some static or dynamic properties of the object.<br>
<br>
4. Create new extension for this. (more complicated)<br>
Problems:<br>
- 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.<br>
<br>
5. Put it into different extensions - reservation_id and
launch_index into os-multiple-create, root_device_name into
os_extended_volumes, .... (most complicated)<br>
Problems:<br>
- 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.<br>
<br>
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.<br>
<br>
Please let me know what you think.<br>
<br>
Best regards,<br>
Alex Levine<br>
<br>
<div class="moz-cite-prefix">On 2/16/15 12:45 PM, Alex Xu wrote:<br>
</div>
<blockquote
cite="mid:CAH7mGav0E9LsDk4n9zUpD6ETVL7hBdp9bZNuKkeWpd4WyTVeZA@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">2015-02-16 9:47 GMT+08:00 Christopher
Yeoh <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:cbkyeoh@gmail.com" target="_blank">cbkyeoh@gmail.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr">Hi,
<div><br>
</div>
<div>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?</div>
<div><br>
</div>
<div>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:</div>
<div><br>
</div>
<div><span
style="color:rgb(0,0,0);font-family:sans-serif"> </span><a
moz-do-not-send="true"
href="http://docs.openstack.org/developer/nova/devref/api_microversions.html"
style="text-decoration:none;color:rgb(6,84,172);font-family:sans-serif"
target="_blank">http://docs.openstack.org/developer/nova/devref/api_microversions.html</a><br>
</div>
<div><br>
</div>
<div>The spec should give some context to what we are
trying to do with microversions:</div>
<div><br>
</div>
<div><a moz-do-not-send="true"
href="http://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/api-microversions.html"
target="_blank">http://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/api-microversions.html</a><br>
</div>
<div><br>
</div>
<div>So in your specific case just some comments:</div>
<div><br>
</div>
<div>- No change necessary to the v2 code
(nova/api/openstack/compute/contriib</div>
<div><br>
</div>
<div>- Will need to modify the v2.1
(nova/api/openstack/compute/plugins/v3) code</div>
<div> - Need to ensure that when run with the users
requesting v2.1 that it still acts like v2</div>
<div> - Given what is in the queue at the moment I'm
guessing yours will probably end up being v2.4 at
least</div>
<div><br>
</div>
<div>- unittests for v2 and v2.1/v2.1 microversions have
mostly been merged to reduce code overhead.</div>
<div> - 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</div>
<div>microversions. </div>
<div><br>
</div>
<div>This <a moz-do-not-send="true"
href="https://review.openstack.org/#/c/140313/"
target="_blank">https://review.openstack.org/#/c/140313/</a>
is a good example of that and is likely to be the
first microversioned code to merge</div>
<div><br>
</div>
<div>- We need to keep api samples for each interface
where the version changes. The above review shows that
and as Alex mentioned</div>
<div>depends on <a moz-do-not-send="true"
href="https://review.openstack.org/155233"
target="_blank">https://review.openstack.org/155233</a>
(currently -2'd but that is only due to some confusion
over whether the microversion</div>
<div>spec was approved for Kilo or not (it was).</div>
<div><br>
</div>
<div>There are a few ways to implement different
behaviour for microversioning, for your specific use
I'd recommend:</div>
<div><br>
</div>
<div>in _extend_server get it to take an extra parameter
version_request and in detail/show get them to pass
req.api_version_request</div>
<div><br>
</div>
<div>replacing:</div>
<div><br>
</div>
<div>
<div> for attr in ['host', 'name',
'reservation_id', 'launch_index',<span
style="white-space:pre-wrap"> </span>30</div>
<div> 'hostname', 'kernel_id',
'ramdisk_id',<span style="white-space:pre-wrap"> </span>31</div>
<div> 'root_device_name',
'user_data']:</div>
</div>
<div><br>
</div>
<div>with something like:</div>
<div><br>
</div>
<div>attrs_to_use = ['host', 'name']</div>
<div><br>
</div>
<div>if (version_requested >=
api_version_request.APIVersionRequest("2.4")"</div>
<div> attrs_to_use.extends(array_of_new_stuff)<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div><br>
</div>
<div>I think we support api_version decorator, see <a
moz-do-not-send="true"
href="https://review.openstack.org/141983">https://review.openstack.org/141983</a></div>
<div>But we need add decorator in the servers' index/detail
and also in this extend method.</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr">
<div><br>
</div>
<div><br>
</div>
<div> for attr in ['host', 'name']:<br>
</div>
<div> blah blah blah</div>
<div><br>
</div>
<div>I think thats likely to be the simplest way to do
it.</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote"><span class="">On Mon, Feb
16, 2015 at 7:19 AM, Alexandre Levine <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:alevine@cloudscaling.com"
target="_blank">alevine@cloudscaling.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px
0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> Thanks a
lot, Alex.<br>
<br>
I thought about this admin-only access
problem.<br>
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:<br>
<br>
class
ExtendedServerAttributesController(wsgi.Controller):<br>
def _extend_server(self, context, server,
instance):<br>
if context.is_admin:<br>
key =
"OS-EXT-SRV-ATTR:hypervisor_hostname"<br>
server[key] = instance['node']<br>
<br>
</div>
</blockquote>
<div><br>
</div>
</span>
<div>So we're really trying to get away from hard
coding any policy because it can</div>
<div>make life harder for both deployers (can't
change a policy without editing code) and
developers (they may</div>
<div>be unaware that something at a lower layer is
preventing something from work because of auth)</div>
<div><br>
</div>
<div>Perhaps a new policy that surpresses just the
ones that you don't want displayed would be an
alternative?</div>
<div>Needs to be very well documented in the
changelong though so deployers understand what
they may need</div>
<div>to change when upgrading.</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>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.</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div>Anyway am happy to continue the discussion via
email/irc. What timezone are you in? We also have
a weekly irc</div>
<div>meeting Friday UTC0000 or I'm happy to help out
on openstack-nova if you ping me (cyeoh).
Generally around work</div>
<div>hours for GMT+10:30</div>
<div><br>
</div>
<div>Regards,</div>
<div><br>
</div>
<div>Chris</div>
<div>
<div class="h5">
<div><br>
</div>
<div> </div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
for attr in ['host', 'name',
'reservation_id', 'launch_index',<br>
'hostname',
'kernel_id', 'ramdisk_id',<br>
'root_device_name',
'user_data']:<br>
if not context.is_admin and attr
in ['host', 'name']:<br>
continue<br>
if attr == 'name':<br>
key =
"OS-EXT-SRV-ATTR:instance_%s" % attr<br>
else:<br>
key = "OS-EXT-SRV-ATTR:%s" %
attr<br>
server[key] = instance[attr]<br>
<br>
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)<br>
<br>
Best regards,<br>
Alex Levine
<div>
<div><br>
<br>
<br>
<div>On 2/15/15 6:18 AM, Alex Xu wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hi, Alexandre,
<div><br>
</div>
<div>I commented on your patch and
nova-specs for some comments and
how to bump micro-version. Hope
that helpful.
<div><br>
</div>
<div>Thanks</div>
<div>Alex</div>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">2015-02-14
15:46 GMT+08:00 Alexandre Levine <span
dir="ltr"><<a
moz-do-not-send="true"
href="mailto:alevine@cloudscaling.com"
target="_blank">alevine@cloudscaling.com</a>></span>:<br>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Ok,
thanks. Sitting tight, waiting
for the API guys.<br>
<br>
Best regards,<br>
Alex Levine
<div>
<div><br>
<br>
On 2/14/15 2:15 AM, Dan
Smith wrote:<br>
<blockquote
class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<blockquote
class="gmail_quote"
style="margin:0px 0px
0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Can we do this on
openstack-dev instead of
private email? It will
also<br>
hopefully keep other
interested parties in
the loop.<br>
</blockquote>
I copied the API guys into
the review initially, but
I think Alexandre<br>
was looking for
clarification if there was
anything else he needed to<br>
do. I was just letting him
know that I think he's in
fine shape for the<br>
moment. I don't think -dev
needs to be copied for
that, unless you want<br>
to poll for comments, but
that's not what he was
asking.<br>
<br>
--Dan<br>
<br>
</blockquote>
<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<br>
</body>
</html>