| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-23 | |||
| 17:53:23 | mriedem | neutron doesn't have microversions | |
| 17:53:29 | mriedem | and nova aggregates don't have anything to do with neutron | |
| 17:53:38 | mriedem | nova doesn't pass a microversion through it's compute API to neutron | |
| 17:53:48 | jgwentworth | you can pass microversions with the novaclient python bindings, so the neutron plugin could do that, I think | |
| 17:53:49 | mriedem | microversions in config files isn't a thing | |
| 17:54:11 | mriedem | neutron is a client, | |
| 17:54:13 | jgwentworth | he's talking about some kinda neutron plugin that creates nova aggregates and adds hosts to aggregates when using the routed provider network segments stuff | |
| 17:54:19 | mriedem | of the placement API (and compute API?), | |
| 17:54:28 | mriedem | so neutron, as a client, will need to specify a microversion when it makes its own requests | |
| 17:54:33 | mriedem | if they require some minimum microversion | |
| 17:55:00 | mriedem | this is the same thing as cinder calling the compute os-server-external-events API with a microversion to pass volume-extended events | |
| 17:55:32 | mriedem | https://github.com/openstack/cinder/blob/master/cinder/compute/nova.py#L207 | |
| 17:56:35 | rybridges | ya jgwentworth gets what I am doing. So in my case, the openstack network subnet create command is creating the aggregate for me. I never ask nova explicitly myself to do it, it happens in the backend as part of the subnet create command. So I need to pass the microversion into the subnet create command maybe.. I can try that | |
| 17:57:46 | jgwentworth | rybridges: here is what I was talking about, when the client object is instantiated, a microversion can be specified, but I think there's also a way to specify per call https://docs.openstack.org/python-novaclient/pike/reference/api/index.html#usage | |
| 17:58:21 | jgwentworth | not seeing that in this doc tho | |
| 18:01:50 | jgwentworth | actually, not seeing a way to specify a microversion per-call in the novaclient python API | |
| 18:02:45 | mriedem | fried_rolls: hopefully i've word-smithed this well enough https://review.openstack.org/#/c/555481/ | |
| 18:03:07 | mriedem | rybridges: you should not have to pass through a compute api version to neutron | |
| 18:03:18 | mriedem | if neutron is going to create aggregates in nova, and needs the uuid, then it must use at least microversion 2.41 | |
| 18:03:23 | mriedem | else it's a bug | |
| 18:04:01 | mriedem | there is not a way to specify a microversion per call in novaclient's python binding API, as it's stored on the client object when it's constructed, | |
| 18:04:16 | mriedem | you could probably mutate the internals of the client object, but we don't have a supported hook for doing that | |
| 18:04:38 | rybridges | okay thanks mriedem thtat is helpful to know | |
| 18:05:02 | rybridges | The uuid is not being returned by the python novaclient when an aggregate is created from neutron, that i know for sure | |
| 18:05:23 | leakypipes | giblet: small request in review. | |
| 18:06:04 | mriedem | where in the neutron code does neutron create a nova host aggregate? | |
| 18:06:06 | rybridges | so maybe this code in neutron that instantiates the client is not correct and/or is not instantiating the python novaclient with the correct microversion | |
| 18:06:09 | mriedem | https://github.com/openstack/neutron/blob/stable/ocata/neutron/services/segments/placement_client.py#L163 is NOT nova | |
| 18:06:25 | mriedem | placement aggregates != nova host aggregates | |
| 18:06:28 | mriedem | completely different REST APIs | |
| 18:06:49 | rybridges | right here: https://github.com/openstack/neutron/blob/master/neutron/services/segments/plugin.py#L221 | |
| 18:06:56 | rybridges | this is going thru nova client, not placement client | |
| 18:06:58 | rybridges | to create the aggregate | |
| 18:07:12 | openstackgerrit | Jay Pipes proposed openstack/nova master: tests for alloc candidates with nested and traits https://review.openstack.org/531899 | |
| 18:07:12 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: resource requests for nested providers https://review.openstack.org/554529 | |
| 18:07:21 | leakypipes | fried_rolls: ok, ready for your re-re-re-review ^^ | |
| 18:07:28 | leakypipes | figleaf: you too :) | |
| 18:07:45 | mriedem | rybridges: https://github.com/openstack/neutron/blob/master/neutron/services/segments/plugin.py#L48 | |
| 18:07:49 | mriedem | novaclient is created with 2.41 | |
| 18:07:52 | mriedem | so it's using 2.41 | |
| 18:08:03 | rybridges | heh yup | |
| 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/ | |