| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-03-17 | |||
| 14:16:23 | mriedem | dansmith: ooo i smell a customer bug | |
| 14:16:56 | mriedem | dansmith: tests where? novaclient? | |
| 14:17:00 | mdbooth | kashyap: I'd be interested to see the result if you create 2 sparse files with loopback devices, and copy between the loopback devices | |
| 14:17:08 | dansmith | mriedem: hang on, linking | |
| 14:17:08 | mdbooth | Is the result sparse? | |
| 14:17:13 | mriedem | edmondsw: we need some scale testing first, | |
| 14:17:37 | kashyap | Always asks tricky questions on a Friday, mdbooth... | |
| 14:17:58 | mdbooth | kashyap: Hopefully it's just a little reconfiguration of the test you've already got | |
| 14:18:04 | mdbooth | I think you've already done the hard work :) | |
| 14:18:04 | kashyap | mdbooth: I will let you know, once I come back from my bike ride. My eyes are aching | |
| 14:18:05 | mriedem | edmondsw: raj_sing- is the lead on that stuff i believe. we have service user tokens enabled in the nova-next job, but as part of the original spec we had talked about the need for some scale testing to stress it to force the usage of the service user tokens, and to stress keystone since it has to do double duty token-wise per request now. | |
| 14:18:15 | dansmith | mriedem: added a comment with links | |
| 14:18:25 | mriedem | edmondsw: https://specs.openstack.org/openstack/nova-specs/specs/ocata/approved/use-service-tokens.html#performance-impact | |
| 14:18:53 | mriedem | "Rally benchmark tests will be ran with and without the “service_user” config options set to compare the results for long running tasks like snapshot or live migration." | |
| 14:19:14 | mriedem | edmondsw: if you have some people familiar with scale testing and rally, it would be helpful to pitch in on the testing there | |
| 14:19:25 | mriedem | i'm not sure if raj_sing- or the osic people are focusing on that right now | |
| 14:19:27 | lbragstad | aunnam around? | |
| 14:20:07 | mriedem | dansmith: i wouldn't trust the unit tests at all, | |
| 14:20:20 | mriedem | dansmith: i'd probably just write a functional test in the novaclient tree that does what you need for how this is supposed to work | |
| 14:20:27 | edmondsw | mriedem that all makes sense. We don't use rally but we do some scale testing. I can ask about trying this there | |
| 14:20:30 | dansmith | mriedem: clearly not, the same tests pass before and after this | |
| 14:20:30 | mriedem | see it break on the bug, and then show it passing with the fix | |
| 14:20:32 | kashyap | mdbooth: Quick clarification, before I head out for a few: IIUC, you want the loopback device to be the overlay, yes? | |
| 14:20:45 | mriedem | dansmith: like what i've been doing with the functional regression tests in nova lately | |
| 14:21:09 | mdbooth | kashyap: I want both source and destination to be loopback devices backed by sparse files | |
| 14:21:22 | mdbooth | kashyap: They should both be the same size | |
| 14:21:34 | mdbooth | kashyap: The source should contain some data, but the dest should initially be blank | |
| 14:21:34 | mriedem | edmondsw: cool. i'm thinking a long-running volume-backed migration where the token will expire and have to be revalidated for cinder and neutron, | |
| 14:21:47 | dansmith | mriedem: okay I forgot about the functional ones in here.. looks like we don't have any for aggregates | |
| 14:21:50 | mriedem | edmondsw: or a long-running snapshot of a large instance (note you'll need the unmerged glance patches for that) | |
| 14:22:27 | mriedem | dansmith: at first glance i'm not seeing anyway | |
| 14:22:33 | mriedem | but they are pretty simple to add | |
| 14:22:56 | mriedem | like https://github.com/openstack/python-novaclient/blob/master/novaclient/tests/functional/v2/legacy/test_extended_attributes.py | |
| 14:22:59 | dansmith | yeah, I'll work on it | |
| 14:23:01 | mriedem | specify the base 2.1 version, | |
| 14:23:05 | edleafe | kashyap: mdbooth: still trying to get the repro for the failure. Didn't give up (yet) :) | |
| 14:23:07 | kashyap | mdbooth: Okay, noted. Just to restate: The backing file(s) must be sparse; and the overlays are loopback devices -- then try a copy among the overlays and see if sparseness is preserved | |
| 14:23:08 | mriedem | extend base class, and that gives you most of what you need | |
| 14:23:12 | mriedem | self.nova() runs the command | |
| 14:23:21 | mdbooth | kashyap: Bingo | |
| 14:23:29 | kashyap | edleafe: Don't give up! One simply does not give up in #openstack-nova channel! | |
| 14:23:38 | mdbooth | kashyap: I think that accurately represents the issue as described | |
| 14:23:57 | kashyap | Okay, with that clarity, bbiab | |
| 14:24:01 | edleafe | kashyap: heh, I figured it was taking me so long you might have thought that I just went back to bed or something | |
| 14:24:25 | ijw | The Nova team has beds now? | |
| 14:24:31 | ijw | Luxury. | |
| 14:24:37 | edleafe | Indeed! | |
| 14:24:51 | mriedem | i have a dugout in the dirt | |
| 14:24:55 | mriedem | it serves my needs | |
| 14:27:07 | markus_z | mriedem: AFAIK I provided all information for your concerns on https://review.openstack.org/#/c/406898/ Can I do anything else there? | |
| 14:30:30 | mriedem | markus_z: i've removed the -1 | |
| 14:30:37 | markus_z | thanks | |
| 14:31:56 | mriedem | markus_z: so basically there are some things backported, like the console refactor patches, which were not functionally needed, but made the target bug fix backport easier | |
| 14:32:25 | mriedem | and all of those groundwork backports are already merged by now anyway | |
| 14:33:19 | markus_z | mriedem: The refactor patches were not backported as they weren't functionally needed. That's why there are conflicts. | |
| 14:34:18 | markus_z | *if* we would have backported the "groundwork" patches, then there wouldn't have been conflicts. | |
| 14:34:35 | mriedem | sure, but that refactor series also introduced a regression in ocata, | |
| 14:34:40 | mriedem | the one about xen and libvirtd | |
| 14:34:46 | mriedem | *virtlogd | |
| 14:35:04 | markus_z | ah, damn, you're right | |
| 14:35:13 | mriedem | right, so we don't want those backports | |
| 14:35:15 | mriedem | for the refactor patches | |
| 14:35:21 | mriedem | or did we backport that to newton? | |
| 14:35:36 | markus_z | sec, I have to check the fix again, need a minute | |
| 14:35:58 | mriedem | looking at the topic branch for newton i don't think we did https://review.openstack.org/#/q/topic:%22bug+1455252%22 | |
| 14:36:23 | mriedem | i think that was https://review.openstack.org/#/c/385367/ | |
| 14:36:41 | mriedem | hmm maybe not | |
| 14:38:42 | markus_z | That was your fix: https://review.openstack.org/#/c/442550/ | |
| 14:40:43 | markus_z | I think it was this one: https://review.openstack.org/#/c/407450/3/nova/virt/libvirt/driver.py | |
| 14:41:32 | markus_z | yep, pretty sure. That's where I screwed up the log_path. | |
| 14:41:41 | mriedem | yup | |
| 14:41:45 | markus_z | That's not backported. | |
| 14:41:49 | mriedem | ok | |
| 14:43:06 | raj_sing- | mriedem: edmondsw Performance testing with service token enabled is part of our plan for Pike. I am not sure yet how to do that, but will focus once glance patch land. Currently we are debugging some errors on that patch. | |
| 14:43:13 | mriedem | markus_z: +W my german friend | |
| 14:43:29 | mriedem | sorry for the delay | |
| 14:43:30 | edmondsw | raj_sing- great, tx | |
| 14:44:53 | mriedem | mtreinish: sdague: can you take a look at these ocata backports? fixes the retry regression: https://review.openstack.org/#/q/topic:bug/1671648+branch:stable/ocata | |
| 14:45:07 | markus_z | mriedem: Thanks a lot my american hero ;P | |
| 14:45:23 | gibi | mriedem, mdbooth: I looked into the circular reference bug you found yesterday. Here is the easiest way to solve it https://review.openstack.org/#/c/446948/ | |
| 14:45:26 | sdague | mriedem: mtreinish is in singapore, so it's sat already | |
| 14:45:27 | mriedem | mtreinish: what was the anime new york hero guy again? | |
| 14:45:31 | mriedem | damn | |
| 14:45:46 | mriedem | bauzas: can you take a pass through these backports? https://review.openstack.org/#/q/topic:bug/1671648+branch:stable/ocata | |
| 14:46:49 | markus_z | frickler: Got a second about https://review.openstack.org/#/c/444164/3 ? That's the VNC setup patch. | |
| 14:49:20 | Dinesh_Bhor | Hi all, Can someone take a look at these two small patches: https://review.openstack.org/#/c/445338/ , https://review.openstack.org/#/c/445782/ Both are having one +2. | |
| 14:52:42 | openstackgerrit | Sean Dague proposed openstack/nova master: Improve descriptions for hostId, host, and hypervisor_hostname https://review.openstack.org/446761 | |
| 14:53:03 | sdague | mriedem / melwitt how about that wording ^^^^ | |
| 14:55:04 | mriedem | sdague: typos | |
| 14:55:12 | mriedem | plus other unaddressed stuff from PS1 | |
| 14:55:22 | mriedem | otherwise the new wording is good, and the example of why it's useful | |
| 14:55:51 | sdague | mriedem: I'll fix the typos, I think the adminstrator only adds are just consistent with other fields that have it | |
| 14:55:54 | sdague | so are fine | |
| 14:56:11 | mriedem | i'm pretty sure nothing else in the os-hypervisors api ref says "this field is only for admins" | |
| 14:56:31 | mriedem | https://developer.openstack.org/api-ref/compute/?expanded=show-hypervisor-details-detail#show-hypervisor-details | |
| 14:56:51 | mriedem | so if we say that for hypervisor_hostname in that API ref, then say it for all, | |
| 14:56:52 | mriedem | or none | |
| 14:57:05 | mriedem | if you're going to chew gum in class, you have to bring enough for everyone | |
| 14:57:47 | openstackgerrit | Sean Dague proposed openstack/nova master: Improve descriptions for hostId, host, and hypervisor_hostname https://review.openstack.org/446761 | |
| 14:58:04 | sdague | damn, the inline editor doesn't let you make 2 edits as once | |