| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-23 | |||
| 16:53:29 | cdent | cool, my stuff is very spikey at the moment but almost working | |
| 16:53:36 | leakypipes | cdent: just trying to get fried_rolls's update provider tree series reviewed right now | |
| 16:53:41 | leakypipes | cdent: coolio. | |
| 16:55:33 | rybridges | mlavalle: Here is debug output http://paste.openstack.org/show/710270/ | |
| 17:05:27 | cfriesen | bauwser: question for you..if an operator doesn't want to expost a host as NUMA-aware, why not just reboot with "numa=off" on the kernel boot args? | |
| 17:09:37 | openstackgerrit | Elod Illes proposed openstack/nova stable/ocata: Functional test for regression bug #1713783 https://review.openstack.org/505160 | |
| 17:09:38 | openstack | bug 1713783 in OpenStack Compute (nova) ocata "After failed evacuation the recovered source compute tries to delete the instance" [High,In progress] https://launchpad.net/bugs/1713783 - Assigned to Balazs Gibizer (balazs-gibizer) | |
| 17:15:37 | openstackgerrit | Elod Illes proposed openstack/nova master: Functional test: cold migrate to compute down https://review.openstack.org/496280 | |
| 17:29:51 | openstackgerrit | Tyler Blakeslee proposed openstack/nova master: Add __repr__ for NovaException https://review.openstack.org/555812 | |
| 17:30:08 | openstackgerrit | Jay Pipes proposed openstack/nova-specs master: mirror nova host aggregates to placement API https://review.openstack.org/545057 | |
| 17:32:08 | openstackgerrit | Balazs Gibizer proposed openstack/nova-specs master: Network bandwidth resource provider https://review.openstack.org/502306 | |
| 17:35:12 | giblet | mriedem, leakypipes, mlavalle, rubasov: I've published a new rev from the bandwidth spec covering two new issues 1) simulating neutron backend selection with a new scheduler weigher 2) handling the mapping between physical resource consumption and the resource claim https://review.openstack.org/#/c/502306 | |
| 17:35:41 | sahid | cfriesen: is the set is empty so we use the default behavior of hw:emulator_threads_policy="share" | |
| 17:35:50 | sahid | i will update the spec for monday | |
| 17:41:47 | leakypipes | giblet: reviewing it as we speak... | |
| 17:42:13 | mriedem | rybridges: aggregate uuids were in a later microversion, openstack CLI defaults to 2.1, so if you want the uuid in the openstack aggregate show output, you need to opt into the microversion | |
| 17:42:51 | mriedem | openstack aggregate list --openstack-compute-api-version 2.41 | |
| 17:42:54 | mriedem | something like that | |
| 17:43:14 | mriedem | --os-compute-api-version i mean | |
| 17:45:00 | rybridges | ok thanks mriedem. I can try that. Is there a way to tell nova to use that microversion on the backend as well? That may work for me as a user on the CLI, but the backend also needs to be able to use that microversion as well | |
| 17:48:26 | jgwentworth | maybe some progress has been made but yesterday rybridges said there weren't any hosts in the nova_api.aggregate_hosts table, proving that the request to add the host to the aggregate never made it there | |
| 17:48:49 | mriedem | rybridges: i don't understand your question | |
| 17:48:54 | jgwentworth | so not a microversion showing the uuids issue | |
| 17:48:54 | mriedem | what is "the backend"? | |
| 17:49:06 | openstackgerrit | Merged openstack/nova master: Always deallocate networking before reschedule if using Neutron https://review.openstack.org/520248 | |
| 17:49:27 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/queens: Always deallocate networking before reschedule if using Neutron https://review.openstack.org/555418 | |
| 17:50:37 | mriedem | rybridges: specifying --os-compute-api-version 2.x on the CLI passes that in a header to the compute REST API, which then processes that single request with that microversion | |
| 17:52:19 | rybridges | mriedem: What I mean is.. I need neutron to also use the correct microversion when it creates aggregates. Like in this call: https://github.com/openstack/neutron/blob/stable/ocata/neutron/services/segments/plugin.py#L224 | |
| 17:52:55 | rybridges | I realize i can pass the microversion manually when I am running on the CLI, but how does neutron know to use the right microversion when it needs to create aggregates on my behalf? | |
| 17:53:12 | rybridges | I am guessing there is some configuration somewhere in neutron.conf or nova.conf where I can specify the microversion? | |
| 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: placement: resource requests for nested providers https://review.openstack.org/554529 | |
| 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: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 | |