Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-03-23
18:08:05 rybridges thats pretty strange
18:08:26 rybridges doesnt make sense why the uuid is not returned. i cannot print it. and any call that references it gets swallowed
18:09:03 mriedem the POST /os-aggregates API ref says that uuid is returned https://developer.openstack.org/api-ref/compute/#create-aggregate
18:09:14 mriedem so which version of novaclient are you using?
18:09:37 mriedem 7.1.2? https://github.com/openstack/requirements/blob/stable/ocata/upper-constraints.txt#L332
18:10:03 rybridges 7.1.3 looks like
18:10:36 mriedem anyway, this is the object you get in novaclient https://github.com/openstack/python-novaclient/blob/7.1.2/novaclient/v2/aggregates.py#L21
18:10:50 mriedem it's just an object that extends dict and has the POST response body as attributes
18:10:53 mriedem so 'uuid' should be in there
18:11:57 artom cfriesen, sean-k-mooney[m], thanks for the reviews guys. Busy with some downstream stuff, so not as responsive as I'd like
18:12:15 artom Can we settle on the scope of the spec though? Specifically, include or not PCI stuff
18:12:16 mriedem this is the code that returns the aggregate response body https://github.com/openstack/nova/blob/stable/ocata/nova/api/openstack/compute/aggregates.py#L204
18:12:41 artom If we go with EPA as sean-k-mooney[m]'s saying, we'd kinda have to, but I'm worried about scope creep, and actually finishing it this cycle
18:13:09 mriedem and i know that works because otherwise this response, used in our testing for 2.41, would fail https://github.com/openstack/nova/blob/stable/ocata/doc/api_samples/os-aggregates/v2.41/aggregate-post-resp.json
18:14:15 rybridges Yea that makes sense mriedem. I realize things would break in tests if the uuid actually wasnt being returned. I did just see something interested though: http://paste.openstack.org/show/710369/
18:14:57 rybridges Looks like maybe my nova backend does not support microversions for some reason. Perhaps that is the problem. I cannot instantiate a client with a microversion at all
18:15:17 mriedem first, you don't need to specify a specific microversion on the nova CLI since the nova CLI opts into, by default, the latest available between the server and client
18:15:42 mriedem as for that 'does not support microversions' stuff, idk what you guys do to hack things up for your own api extensions
18:15:59 rybridges we have 0 patches in the environment i am using right now
18:16:01 rybridges 0
18:16:34 rybridges jgwentworth said earlier that i can pass the microversion into the backend as an argument so i figured i would try it. thats all.
18:16:50 mriedem "pass the microversion into the backend" isn't a thing
18:17:43 mriedem just do a simple curl request to your compute endpoint URL
18:17:47 mriedem that will give you the version document
18:18:09 mriedem and https://github.com/openstack/python-novaclient/blob/5af4a8edd88187e0a21c665a6e91fcdcd8ced06c/novaclient/api_versions.py#L265 is complaining that there is no min/max version in your compute endpoint version doc
18:18:28 jgwentworth I think we're just using different words. but in the novaclient python API bindings, you *can* specify a microversion when the client object is created, in fact, I think you have to. if it allows you not to, then it will default to the lowest/base microversion
18:18:46 cfriesen artom: no worries, I'm in the same boat
18:19:00 mriedem jgwentworth: yes and as i pointed out above, neutron is creating novaclient with version 2.41
18:19:02 cfriesen artom: leave PCI out for now
18:19:03 mriedem hard-coded
18:19:03 jgwentworth I was mistaken that there was some way to specify microversion *per call* after instantiating the client object. I am not seeing a way to do that
18:19:23 jgwentworth okay, so that is taken care of. so rybridges that code is calling with 2.41 already
18:19:24 cfriesen artom: there are additional complications for PCI that merit a separate spec
18:19:25 mriedem the novaclient python API bindings default to 2.1, the CLI defaults to the latest available between the server and what the client understands
18:19:32 jgwentworth right
18:20:19 artom cfriesen, cool, good to know you'll back be on that :)
18:20:22 artom *back me
18:20:29 openstackgerrit Chris Dent proposed openstack/nova master: WIP: Support for forbidden traits in placement https://review.openstack.org/554665
18:20:56 mriedem fried_rolls: want to backport https://review.openstack.org/#/c/554759/ to queens?
18:21:45 rybridges Ok so if the CLI defaults to the latest version that the server understands, then my server does not understand 2.41. If it did, then I would see the uuid in the response body of this call: http://paste.openstack.org/show/710386/
18:23:02 rybridges either that or its not defaulting to the highest version available but rather the lowest base
18:23:30 jgwentworth you're running ocata, yes? you should have it https://docs.openstack.org/nova/latest/reference/api-microversion-history.html#id37
18:23:31 mriedem {"version": {"status": "SUPPORTED", "updated": "2011-01-21T11:33:21Z", "links": [{"href": "http://XXX:8774/v2/", "rel": "self"}, {"href": "http://docs.openstack.org/", "type": "text/html", "rel": "describedby"}], "min_version": "", "version": "", "media-types": [{"base": "application/json", "type": "application/vnd.openstack.compute+json;version=2"}], "id": "v2.0"}}
18:23:39 mriedem that's your server's compute endpoint url version doc
18:23:46 mriedem note there is no min or version
18:23:50 mriedem version == max
18:23:54 mriedem so yeah, your cloud is f'ed
18:24:17 jgwentworth yeah ... you have ocata right rybridges?
18:24:24 rybridges yes i am running stable/ocata
18:24:36 jgwentworth hm, wtf
18:24:42 superdan this seems like #openstack fodder, no?
18:24:54 mriedem after 2 days of debugging this issue, yes
18:24:58 mriedem this is BASIC stuff
18:25:05 superdan especially if this is just installation basically
18:25:05 superdan yeah
18:25:27 mriedem where are sean-k-mooney[m] and cfriesen around when i need to flood this channel with placement and NFV talk?
18:26:15 figleaf leakypipes: ack. Will re-review in a few
18:30:11 cdent mriedem, superdan : if you like less code, the requirements dependency for removing microversion stuff in placement to a library has been improved: https://review.openstack.org/#/c/550265/
18:30:42 cdent sigh: s/improved/approved/
18:30:56 mriedem i like more code on fridays
18:31:03 openstackgerrit Merged openstack/nova master: trivial: omit condition evaluations https://review.openstack.org/545248
18:31:13 openstackgerrit Merged openstack/nova master: Stop using mox in virt/xenapi/image/test_vdi_through_dev.py https://review.openstack.org/342682
18:31:15 cdent mriedem: you never were any fun
18:36:50 cdent leakypipes you might also like https://review.openstack.org/#/c/550265/ <- placement using microversion-parse 0.2.1
18:47:00 openstackgerrit Eric Fried proposed openstack/nova stable/queens: Change compute mgr placement check to region_name https://review.openstack.org/555901
18:47:05 fried_rolls mriedem: Done ^
18:47:20 fried_rolls leakypipes: ack
18:48:10 mriedem thanks
18:48:26 jgwentworth indeed looks like it's an installation problem. from the novaclient --debug output, it's talking to the /v2 nova endpoint which doesn't do microversions. it's supposed to be /v2.1 (in the service catalog)
18:48:49 cdent fried_rolls: wasn't half the bug there that people should have to express either region_name or os_region_name if they are using the default? not just that they were using the wrong one?
18:49:49 fried_rolls cdent: The bug was that, if you specified os_region_name, you got a deprecation warning, but it worked. But if you specified region_name, it just didn't work at all.
18:50:11 fried_rolls but yeah, pretty sure you have to specify one or the other.
18:50:15 fried_rolls which... is kind of a pity, really.
18:50:19 cdent that seems wrong
18:53:07 figleaf leakypipes: can you explain what's going on in https://review.openstack.org/#/c/554529/2/nova/api/openstack/placement/objects/resource_provider.py@3055 ?
18:56:32 figleaf leakypipes: oh, never mind. I think I got it
19:02:20 sean-k-mooney[m] mriedem: today on vacation
19:02:34 JunoMan Sorry for wasting your time with the microversion confusion y'all. We missed that in the kilo release notes.
19:03:01 mriedem sean-k-mooney[m]: was just joking, probably missed the context
19:03:02 mriedem ignore
19:03:09 sean-k-mooney[m] mriedem: also after yesterday i think i need to not think about numa/nfv for at least a day or two
19:05:00 mriedem superdan: the reader/writer fixes are ready to go imo https://review.openstack.org/#/q/topic:bug/1746509+(status:open+OR+status:merged)
19:06:23 sean-k-mooney[m] mriedem: hehe ya i know. i may have installed riot.im on my phone and now get irc routed too me now. it has its pros and cons
19:06:43 jroll JunoMan: excellent friday nick
19:09:50 superdan mriedem: okay will look in a few
19:11:19 openstackgerrit Julia Kreger proposed openstack/nova master: WIP: Add microversion to ironic client wrapper call https://review.openstack.org/554762
19:11:50 jgwentworth will superdan strike down my code comment sentence? time will tell
19:12:22 superdan sources from beyond the grave say.....PLAUSIBLE
19:12:31 jgwentworth lol
19:18:13 openstackgerrit Eric Berglund proposed openstack/nova master: PowerVM Driver: vSCSI volume driver https://review.openstack.org/526094
19:28:45 openstackgerrit Matt Riedemann proposed openstack/nova stable/pike: Always deallocate networking before reschedule if using Neutron https://review.openstack.org/555907
19:45:33 openstackgerrit Merged openstack/nova master: Updated from global requirements https://review.openstack.org/555576
20:02:38 openstackgerrit melanie witt proposed openstack/nova stable/queens: Add functional regression test for bug 1746509 https://review.openstack.org/555914
20:02:39 openstack bug 1746509 in OpenStack Compute (nova) "TypeError: Can't upgrade a READER transaction to a WRITER mid-transaction" [Medium,In progress] https://launchpad.net/bugs/1746509 - Assigned to melanie witt (melwitt)
20:02:39 openstackgerrit melanie witt proposed openstack/nova stable/queens: Move _make_instance_list call outside of DB transaction context https://review.openstack.org/555915
20:06:22 openstackgerrit melanie witt proposed openstack/nova stable/pike: Add functional regression test for bug 1746509 https://review.openstack.org/555058
20:06:23 openstack bug 1746509 in OpenStack Compute (nova) "TypeError: Can't upgrade a READER transaction to a WRITER mid-transaction" [Medium,In progress] https://launchpad.net/bugs/1746509 - Assigned to melanie witt (melwitt)
20:06:23 openstackgerrit melanie witt proposed openstack/nova stable/pike: Move _make_instance_list call outside of DB transaction context https://review.openstack.org/555923
20:06:49 openstackgerrit Konstantinos Samaras-Tsakiris proposed openstack/nova master: Add `hide_hypervisor_id` flavor extra_spec https://review.openstack.org/555861
20:14:21 mlavalle rybridges: yeah, you are not getting the uuid attribute from the API. If you look at the response in http://paste.openstack.org/show/710244/, I get a header with the API version: X-OpenStack-Nova-API-Version: 2.60. Yours doesn't even have that header

Earlier   Later