| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-02-25 | |||
| 16:02:16 | mriedem | yonglihe: i'll try to get to that one | |
| 16:03:23 | yonglihe | thanks. | |
| 16:04:26 | yonglihe | i suppose all stuff piled up at end of dev cycle, sorry for that. | |
| 16:12:37 | mriedem | np, it always happens | |
| 16:20:50 | bauzas | stephenfin: +Waboom | |
| 16:25:33 | openstackgerrit | Merged openstack/nova master: Refactor "networks" processing in ServersController.create https://review.openstack.org/633594 | |
| 16:27:31 | stephenfin | bauzas: Tank u | |
| 16:28:23 | stephenfin | .--._____, | |
| 16:28:23 | stephenfin | .-='=='==-, " | |
| 16:28:23 | stephenfin | (O_o_o_o_o_O) | |
| 16:33:29 | yonglihe | -:) | |
| 16:40:09 | openstackgerrit | Stephen Finucane proposed openstack/nova-specs master: Add 'flavor-extra-spec-image-property-validation' spec https://review.openstack.org/638734 | |
| 16:42:36 | openstackgerrit | Matt Riedemann proposed openstack/nova master: [Doc] Best practices for effectively tolerating down cells https://review.openstack.org/638173 | |
| 16:43:11 | tssurya | thanks mriedem ^ | |
| 16:43:15 | mriedem | np | |
| 16:57:49 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Fup for the bandwidth series https://review.openstack.org/639159 | |
| 16:58:10 | gibi | mriedem: your comments for the bandwidth series are fixed in ^^ | |
| 16:58:54 | gibi | jaypipes, efried: thanks for the comments in the bandwidth series, I will update https://review.openstack.org/639159 with your comments as well, possibly tomorrow | |
| 17:00:44 | artom | Object equality in tests in a PITA | |
| 17:00:48 | artom | *is | |
| 17:01:11 | artom | Expect call: Flavor(<some stuff>), Actual call: Flavor(<exact same stuff>) | |
| 17:03:49 | artom | *facepalm* | |
| 17:03:54 | artom | No, that's not i :( | |
| 17:03:58 | artom | *it | |
| 17:04:46 | sean-k-mooney | stephenfin: left some comments on you os-vif docs changes most are minor | |
| 17:07:24 | sean-k-mooney | artom: object equality check pending change so you need to reset changes on both object before comparing them | |
| 17:08:06 | sean-k-mooney | otherwise you get X != X issues | |
| 17:10:23 | jaypipes | artom: what sean-k-mooney said is almost always the problem with that. | |
| 17:10:54 | sean-k-mooney | jaypipes: artom we proably should just create a function in the base tescae for comparing objects | |
| 17:11:13 | jaypipes | sean-k-mooney: there was one somewhere I think... maybe dansmith can remember :) | |
| 17:11:22 | sean-k-mooney | e.g. self.assertObjEquals | |
| 17:12:30 | sean-k-mooney | jaypipes: would it break the world if we changed __eq__ in base ovo to ignore the changed state of fields? | |
| 17:12:46 | sean-k-mooney | i assume yes since we have not done so before | |
| 17:12:50 | artom | sean-k-mooney, jaypipes, yeah, so it this case it was dumber than that - my main problem was I had an - and an _ in my fake values | |
| 17:13:02 | sean-k-mooney | oh :) | |
| 17:13:11 | artom | But once that hurdle was over, there was still an object I had to replace with a fake string. | |
| 17:13:45 | artom | But yeah, a more intelligent way of comparing objects would be super | |
| 17:13:46 | jaypipes | hah :) | |
| 17:14:18 | artom | It wouldn't even be that hard - implement __eq__ in the base fields, and then recursively compare fields | |
| 17:15:13 | sean-k-mooney | artom: yes but we dont know if anyting depens on the fact that object comparisons current check the changed fields state of the objects | |
| 17:15:34 | sean-k-mooney | os its not that its hard to do but would it break anything | |
| 17:17:03 | sean-k-mooney | artom: https://github.com/openstack/nova/blob/eb5bdd33052166e4375f924456438f11be03310a/nova/test.py#L704 we have this by the way | |
| 17:17:37 | artom | sean-k-mooney, that's not useful when you're asseting call param tho | |
| 17:17:50 | artom | Anyways, it's a pain, but all things considered a minor one | |
| 17:33:22 | mriedem | artom: i've got some object equality test utils in my cross-cell resize series, sec | |
| 17:36:51 | mriedem | artom: https://review.openstack.org/#/c/627892/15/nova/tests/unit/conductor/tasks/test_cross_cell_migrate.py@193 | |
| 17:44:03 | mriedem | dansmith: random question, when detaching the root volume of a server and attaching a new root volume, would you expect the device name on that bdm to change? or remain vda or whatever? | |
| 17:44:12 | mriedem | i would expect it to *not* change | |
| 17:44:18 | mriedem | since the boot_index is still 0 | |
| 17:44:32 | mriedem | and the disk_bus and device_type can't change | |
| 17:49:51 | sean-k-mooney | mriedem: i think the only time we would expect that it could change would be a rebuild with a different image or perhaps a volume retype operation. so if your question was related to the cross cell resize i think that is a safe assumtion to make | |
| 17:50:20 | mriedem | it's not | |
| 17:50:32 | mriedem | it's for Kevin_Zheng's root bdm attach/detach series | |
| 17:50:45 | sean-k-mooney | oh ok | |
| 17:51:21 | sean-k-mooney | am well if you detach attach anoth volume and then attach the root again i guess it could change | |
| 17:51:42 | sean-k-mooney | i dont know that code that well however | |
| 17:52:15 | mriedem | https://review.openstack.org/#/c/614750/34/nova/compute/manager.py | |
| 17:52:57 | mriedem | if i boot from volume and get vda, then attach a data volume which is vdb, then detach the root volume and attach another root volume, would i expect to have that as vda or vdc? | |
| 17:53:10 | mriedem | i would expect vda because the root volume being higher than the data volume seems wrong | |
| 17:54:02 | dansmith | mriedem: yeah, expect the name to remain stable | |
| 17:54:25 | sean-k-mooney | mriedem: that might depend on the os and the udev rules. but i would expect it to stay the same. i dont know if it actully would | |
| 17:56:42 | mriedem | well, we also don't guarantee the device name the user requests is honored by the hypervisor anyway | |
| 18:01:04 | artom | mriedem, interesting, but I feel like that's specific to what you're doing with them (which is fine!) | |
| 18:02:19 | sean-k-mooney | mriedem: for the detach attach root volume spec | |
| 18:02:34 | sean-k-mooney | mriedem: is it the same volume or can it be any volume that is reattached | |
| 18:02:37 | artom | And as far as I can tell _assertEqualObjects doens't handle nested objects | |
| 18:03:15 | artom | Anyways, as I said, it's an annoyance, but a minor one, though it might be worth it to put in the time to do it properly in a single place so that we stop fixing this each in our little corners | |
| 18:04:08 | sean-k-mooney | mriedem: im wondering if we supprot reading the hw_disk_bus key form image metadata on a volume | |
| 18:04:55 | sean-k-mooney | i think the answer is no but im checking | |
| 18:10:54 | openstackgerrit | Merged openstack/os-vif master: Fix nits in brctl removal (vif_plug_linux_bridge) https://review.openstack.org/639099 | |
| 18:11:57 | sean-k-mooney | mriedem: it looks like we can get the image meta form the volume https://github.com/openstack/nova/blob/af78b13c24d4abf393d17ac57e9135204ef12b73/nova/utils.py#L928 | |
| 18:12:25 | sean-k-mooney | mriedem: so if we are allowing attaching an arbiatry volume as the new root volume the diskbus could change | |
| 18:12:37 | sean-k-mooney | if it has to be the same volume it wont | |
| 18:14:09 | sean-k-mooney | that is called form https://github.com/openstack/nova/blob/5a09c81af3b438ecbcf27fa653095ff55abb3ed4/nova/compute/api.py#L1057 | |
| 18:24:09 | sean-k-mooney | mriedem: ah never mind the propsed change stats the detach will be garded by the instance being shelve offloaded | |
| 18:24:17 | sean-k-mooney | ill update my comment on the patch | |
| 18:25:18 | sean-k-mooney | oh thats the mitaka spec... | |
| 18:27:07 | sean-k-mooney | the stein spech allow detach when the instance is powered off which may not work if the iamge changes | |
| 18:32:29 | openstackgerrit | Merged openstack/python-novaclient master: Handle unicode multi-byte characters https://review.openstack.org/632942 | |
| 18:35:39 | melwitt | o/ | |
| 18:35:57 | sean-k-mooney | melwitt: o/ | |
| 18:36:11 | openstackgerrit | Merged openstack/nova master: Pass resource provider mapping to neutronv2 api https://review.openstack.org/616240 | |
| 18:36:19 | openstackgerrit | Merged openstack/nova master: Recalculate request group - RP mapping during re-schedule https://review.openstack.org/619529 | |
| 18:36:29 | openstackgerrit | Merged openstack/nova master: Add microversion to expose virtual device tags https://review.openstack.org/631948 | |
| 18:36:42 | openstackgerrit | Merged openstack/nova master: api-ref: mark os-cells as deprecated https://review.openstack.org/636708 | |
| 18:36:52 | openstackgerrit | Merged openstack/nova master: Replace ansible --sudo with --become in live_migration/hooks scripts https://review.openstack.org/635308 | |
| 18:48:45 | openstackgerrit | Andrey Volkov proposed openstack/nova master: Check hosts have no instances for AZ rename https://review.openstack.org/509206 | |
| 18:49:55 | mriedem | sean-k-mooney: yeah it can be a different volume | |
| 18:50:50 | sean-k-mooney | mriedem: do you think my concern regarding powered off instance is vlaid | |
| 18:51:04 | sean-k-mooney | mriedem: i updated the comment on the patch | |
| 18:51:40 | mriedem | how would powered off be different from when we unshelve the instance with a new root volume? | |
| 18:52:06 | sean-k-mooney | a powered off instace is associated with a host | |
| 18:52:16 | sean-k-mooney | we read the image metadata form volumes | |
| 18:52:28 | sean-k-mooney | so if you can change the voluems you can change the requirement for the host | |
| 18:52:50 | sean-k-mooney | in unshevle we will hit the schuler | |
| 18:52:57 | sean-k-mooney | but for powered off instnace we dont | |
| 18:53:11 | sean-k-mooney | when we we start it again that is | |
| 18:55:25 | mriedem | yes i see the issue, but i don't think he's reading the new root volume image_meta on unshelve either, | |
| 18:55:36 | sean-k-mooney | a concreate example would be if the instance was pinned and the original volume was create from an image with hw:numa_nodes=1 and the new volume was created form an iamge with hw:numa_node=2 it will invalidate the pinnings | |
| 18:55:39 | mriedem | so as far as i know when we unshelve we're not using the new image meta anyway | |