| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-03-08 | |||
| 03:08:11 | openstackgerrit | Vladik Romanovsky proposed openstack/nova master: libvirt: a method to prepare SPICE console connection https://review.openstack.org/442915 | |
| 03:13:16 | dansmith | diana_clarke: I don't even know that there's history there, so.. no? | |
| 03:17:19 | diana_clarke | dansmith: I'm curious why there was a switch at some point to marker vs. offset. That is, the problem that shift was trying to solve at the expense of an easier API. | |
| 03:17:44 | diana_clarke | (I just followed the pattern) | |
| 03:20:05 | diana_clarke | Off the top of my head, I can't think of another API that uses markers (over offsets). | |
| 03:20:30 | dansmith | diana_clarke: I'm not aware of any shift from offset to marker, so it may have been before my time (or at least before I started paying attention) | |
| 03:21:50 | diana_clarke | dansmith: Welp, recent code uses markers, older code uses markers (that's all I know). | |
| 03:22:18 | diana_clarke | typo: older code uses _offsets__ | |
| 03:24:27 | dansmith | really? what older code uses offsets? | |
| 03:25:30 | dansmith | I see mention of offsets in openstack/api/common, but that's pretty new code, AFAIK | |
| 03:27:53 | dansmith | unless it was just transplanted from somewhere, but I thought all the original pagination was done in db where I see no offsets | |
| 03:28:04 | dansmith | but anyway, I dunno :) | |
| 03:35:16 | alex_xu | dansmith: https://review.openstack.org/#/c/441388/7/nova/api/openstack/compute/simple_tenant_usage.py a comment about optimize the marker | |
| 03:35:26 | dansmith | alex_xu: responding now | |
| 03:35:34 | dansmith | ? | |
| 03:35:34 | dansmith | alex_xu: were you going to comment on the sorting thing too | |
| 03:35:56 | alex_xu | dansmith: yea, I added comment in the PS6 | |
| 03:36:44 | dansmith | alex_xu: ah I see now, thanks | |
| 03:36:50 | alex_xu | dansmith: np | |
| 03:37:36 | dansmith | alex_xu: here is the other one of the pattern: https://github.com/openstack/nova/blob/master/nova/compute/api.py#L2548 | |
| 03:38:04 | alex_xu | dansmith: yes, i'm ok to optimize that in later patch. I just follow a -1 since Matt already -1, to earn a point :) | |
| 03:38:15 | dansmith | haha | |
| 03:38:39 | dansmith | alex_xu: you're a pro now :) | |
| 03:38:51 | alex_xu | yea \o/ | |
| 03:38:57 | dansmith | :) | |
| 04:39:37 | openstackgerrit | Akira KAMIO proposed openstack/nova master: Replace root volume during rebuild https://review.openstack.org/442295 | |
| 05:18:25 | cfriesen | alex_xu: you on? | |
| 05:25:38 | openstackgerrit | Chris Friesen proposed openstack/nova-specs master: add spec for instance flavor API https://review.openstack.org/265282 | |
| 05:29:11 | openstackgerrit | Chris Friesen proposed openstack/nova-specs master: Support Instance Rebuild With Userdata https://review.openstack.org/431052 | |
| 06:01:43 | openstackgerrit | kavitha h r proposed openstack/os-vif master: The Python 3.5 is added https://review.openstack.org/442955 | |
| 06:34:17 | alex_xu | cfriesen: yes | |
| 06:35:21 | openstackgerrit | Akira KAMIO proposed openstack/nova master: Replace root volume during rebuild https://review.openstack.org/442295 | |
| 06:54:14 | cfriesen | alex_xu: if you're still here...I made some comments on https://review.openstack.org/#/c/265282 Also, it occurs to me that the "resize" command currently returns the flavorid. Should we keep that (since it shouldn't be stale)? | |
| 06:55:36 | alex_xu | cfriesen: yea, i'm here. I'm good with your reply, but i guess you misse done https://review.openstack.org/#/c/265282/5/specs/pike/approved/instance-flavor-api.rst@131 | |
| 06:55:40 | alex_xu | s/done/one | |
| 06:55:57 | alex_xu | cfriesen: for resize, let me check | |
| 06:57:22 | cfriesen | whoops, right. will check the rxtx_factor | |
| 06:57:42 | alex_xu | cfriesen: currently we didn't have response from resize | |
| 06:58:23 | alex_xu | cfriesen: and...as I remember, you are in Canada...why you are still wakeup | |
| 06:58:38 | cfriesen | it's 1am and I'm still up. :) | |
| 06:58:49 | alex_xu | cfriesen: ok :) | |
| 06:59:00 | cfriesen | server-action-resize.json.tpl has "flavorRef" which is the Flavor.flavorid | |
| 06:59:12 | alex_xu | cfriesen: that is request | |
| 06:59:42 | alex_xu | the name of that sample file didn't clear about the request/response | |
| 06:59:49 | cfriesen | whoops, you are correct. | |
| 06:59:56 | cfriesen | good, less work | |
| 07:00:01 | alex_xu | heh | |
| 07:00:35 | cfriesen | looks like there is some policy around rxtx_factor...checking deeper | |
| 07:01:15 | alex_xu | cfriesen: https://github.com/openstack/nova/blob/master/nova/policies/flavor_rxtx.py#L21 | |
| 07:04:03 | cfriesen | alex_xu: looks like "os_compute_api:os-flavor-rxtx" applies to show/detail, so it should probably affect the flavor details embedded in the server too | |
| 07:04:26 | alex_xu | cfriesen: yea | |
| 07:05:16 | cfriesen | okay, I'll update the spec | |
| 07:05:33 | alex_xu | cfriesen: thanks | |
| 07:11:07 | Qiming | alex_xu, there? | |
| 07:11:27 | alex_xu | Qiming: yea | |
| 07:11:54 | Qiming | nova api is behaving strangely regarding micro-version | |
| 07:12:32 | alex_xu | Qiming: which case you pointed to? | |
| 07:12:41 | Qiming | I'm trying to get the user_data I set to an instance | |
| 07:12:53 | Qiming | this is only available from 2.3 api | |
| 07:13:00 | Qiming | according to api-ref | |
| 07:13:26 | alex_xu | yea | |
| 07:13:43 | Qiming | btw, in the doc, "OS-EXT-SERV-ATTR:user_data" should be "OS-EXT-SRV-ATTR:user_data", that is a typo | |
| 07:13:54 | Qiming | not the key issue I want to raise here | |
| 07:14:15 | alex_xu | Qiming: but thanks btw | |
| 07:14:48 | Qiming | when I tried 'curl -H 'openstack-api-version: compute 2.3' .... I can get the response with "OS-EXT-SRV-ATTR:user_data" returned | |
| 07:14:49 | openstackgerrit | Chris Friesen proposed openstack/nova-specs master: add spec for instance flavor API https://review.openstack.org/265282 | |
| 07:15:11 | alex_xu | yea | |
| 07:15:26 | Qiming | when I tried openstackclient with --os-compute-api 2.3 --debug, this field and other fields added since 2.3 are missing | |
| 07:15:49 | alex_xu | Qiming: i don't openstackclient support microvresion now | |
| 07:16:03 | alex_xu | s/i don't/i don't think/ | |
| 07:17:03 | Qiming | em... nova responded this in the header: Content-Length: 1464 Content-Type: application/json Openstack-Api-Version: compute 2.3 X-Openstack-Nova-Api-Version: 2.3 Vary: OpenStack-API-Version, X-OpenStack-Nova-API-Version X-Compute-Request-Id: req-efc2a8c9-b37b-43e9-a170-73e1658b3177 Date: Wed, 08 Mar 2017 07:16:20 GMT Connection: keep-alive | |
| 07:17:20 | Qiming | this means ... it should work, right? | |
| 07:18:00 | alex_xu | Qiming: yes...that means OSC request 2.3, and the server response with 2.3 | |
| 07:18:22 | alex_xu | Qiming: but I'm not sure OSC handle 2.3 in the CLI display | |
| 07:18:40 | Qiming | so I think nova-api understands the micro-version api request properly | |
| 07:19:09 | Qiming | I don't care about the CLI output, so I turned on --debug, I want to check the raw response body | |
| 07:19:13 | alex_xu | Qiming: there is talk about implement microversion OSC, so i think OSC didn't implement that | |
| 07:19:32 | alex_xu | Qiming: no new fields in the raw response body? | |
| 07:19:40 | Qiming | yup | |
| 07:19:55 | alex_xu | strange, let me check | |
| 07:20:27 | Qiming | so I am here complaining to you, instead of complaining in another channel | |
| 07:20:57 | Qiming | I was suspecting that nova-api treats 'User-Agent' header in different (buggy) ways | |
| 07:21:07 | Qiming | but that is not true | |
| 07:21:47 | Qiming | I was doubting the 'X-Auth-Token' is causing some problems ... seems that is relevant | |
| 07:22:19 | Qiming | If I'm passing token in this format: -H "X-Auth-Token: {SHA1}e216eff934c3484e8bc2cf1642c736e215c8c369" | |
| 07:22:29 | alex_xu | Qiming: Openstack-API-Version header returned, that means nova-api already know the requested version | |
| 07:22:32 | Qiming | I can never get the fields from the response | |
| 07:22:42 | alex_xu | emm... | |
| 07:22:46 | alex_xu | Qiming: By curl | |
| 07:22:48 | alex_xu | ? | |
| 07:23:17 | Qiming | if I'm passing token in this way: 'X-Auth-Token: 6c9bce0e3a514ad7981fa03f990e5cfc' | |
| 07:23:24 | Qiming | I can get the correct result | |
| 07:23:29 | Qiming | see the difference? | |
| 07:23:30 | alex_xu | Qiming: I guess you can't pass taken with hash token by curl | |
| 07:23:59 | Qiming | that is what I'm seeing from the keystoneauth1 log | |
| 07:24:28 | alex_xu | Qiming: the hash is done by the keystoneauth, for hide the secret thing. if you paste that into the curl, you can't pass the auth | |
| 07:24:39 | Qiming | yes, I realized that | |
| 07:25:02 | Qiming | I was comparing the ways requests are sent from OSC and from cURL | |
| 07:25:38 | Qiming | I believe you can reproduce this easily? | |
| 07:26:34 | alex_xu | Qiming: yea, i'm trying | |