| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-06-06 | |||
| 14:20:33 | mriedem | doesn't mean i should | |
| 14:20:38 | jaypipes | mriedem: ++ | |
| 14:20:41 | mdbooth | mriedem: Agreed. I don't think it's specific to this case, though. | |
| 14:21:01 | mdbooth | mriedem: It doesn't impact the multiattach thing. | |
| 14:21:03 | artom | mriedem, I think the difference here is that, calling os-server-external-events doesn't potentially corrupt data | |
| 14:21:25 | mriedem | you guys are missing the point | |
| 14:21:27 | jaypipes | mdbooth: BTW, I'm not insinuating that you personally have anything to do with this swap_volume() code. Just pointing out I don't think this particular API call belongs in the compute API. | |
| 14:21:28 | artom | For instance, if we discovered that calling it with a certain event caused a VM to go down (suspend your disbelief, work with me) | |
| 14:21:43 | artom | We'd fix that, regardless of how silly the "use case" (or lack thereof) was | |
| 14:21:55 | bhagyashri_s | efried, jaypipes, bauzas: Hi, Addressed review comments on https://review.openstack.org/#/c/560459 and replied to few comments. Request to review the same. Thank you in advanced :) | |
| 14:22:17 | mdbooth | jaypipes: Don't get me wrong, I've wasted many, many curse words on swap_volume. However, I don't see how you can implement this without something like it. | |
| 14:22:54 | mriedem | mdbooth: have you opened a nova bug for this yet? | |
| 14:24:12 | mdbooth | mriedem: No, but I will. I was kinda hoping somebody, either Nova or Cinder, would pipe up with a simple fix. | |
| 14:24:28 | mriedem | mdbooth: i can but wanted a but quick | |
| 14:25:08 | artom | mdbooth, I mean, I did? | |
| 14:25:11 | artom | Return a 400? | |
| 14:25:19 | mdbooth | Oh, I think you're saying that the direct call use case is relevant here because it's all that's stopping us from implementing this in cinder? | |
| 14:25:24 | artom | jaypipes seems on board with it | |
| 14:25:43 | mdbooth | In which case, yeah. | |
| 14:26:03 | mriedem | mdbooth: yes | |
| 14:26:10 | mriedem | i would prefer to just put the blocker in cinder | |
| 14:26:21 | mriedem | reasons are in my ML reply | |
| 14:26:44 | mriedem | 1. source of truth so less racy and 2. no rollbacks for retype or live migration for volumes | |
| 14:26:47 | artom | mriedem, so Cinder would barf if we "fix" it *just* in Nova, right? | |
| 14:26:51 | openstackgerrit | Jan Gutter proposed openstack/nova master: Add support for vrouter HW offloads https://review.openstack.org/572082 | |
| 14:26:55 | mriedem | artom: yes, but way late | |
| 14:27:00 | smcginnis | I haven't been following the discussion at all, but if we want to block something in cinder, make sure it makes sense for use cases outside of nova. | |
| 14:27:05 | mriedem | and then you better pray that cinder rolls back properly | |
| 14:27:26 | mriedem | smcginnis: you probably missed my k8s snark earlier | |
| 14:27:37 | artom | mriedem, so we'd have to 1. block it in cinder early on 2. block it in nova for the ludicrous direct-call case | |
| 14:27:46 | mriedem | how would a volume live migratoin / retype work with k8s when k8s doesn't implement a swap volume callback API? | |
| 14:27:53 | mriedem | artom: i guess | |
| 14:27:59 | mriedem | i can hack something up for the nova side blocker | |
| 14:28:01 | artom | And I then I don't think we'd need a "3. make cinder handle 2" because we'd never get there | |
| 14:28:41 | smcginnis | mriedem + k8s == snark :) | |
| 14:33:15 | openstackgerrit | Matt Riedemann proposed openstack/nova master: WIP: Block swap volume with multiattach volumes https://review.openstack.org/572790 | |
| 14:33:18 | mriedem | there ^ - afk for a couple of hours for a kid's school thing | |
| 14:34:57 | dansmith | mriedem: back for cells meeting? | |
| 14:35:40 | artom | mriedem, https://bugzilla.redhat.com/show_bug.cgi?id=1446446 <--- downstream bug with direct call to volume update | |
| 14:36:05 | openstack | artom: Error: Could not parse XML returned by bugzilla.redhat.com: Unknown host. (https://bugzilla.redhat.com/show_bug.cgi?id=1446446&ctype=xml) | |
| 14:36:20 | artom | openstack, ok :) | |
| 14:36:36 | artom | (It just took me forever to find it) | |
| 14:41:42 | mnaser | dansmith: regarding the build failure limit change, nova does include all weighers by default, right? | |
| 14:41:54 | dansmith | mnaser: yup | |
| 14:42:20 | dansmith | mnaser: you adjust the weight to make a weigher a no-op | |
| 14:42:46 | mnaser | dansmith: cool, with that, its lgtm, there are a few copy-paste thing but it's not a big deal, only if you have to do another revision you can fix it i guess | |
| 14:43:21 | dansmith | mnaser: ah, not copy-paste, but "mriedem decided he wanted to s/boot/build/" and I missed one :) | |
| 14:43:36 | dansmith | oh, | |
| 14:43:42 | dansmith | the ram one is copy pasta yeah | |
| 14:43:58 | mnaser | :P | |
| 14:44:07 | dansmith | I'll update so it's clean since this is backportable | |
| 14:44:08 | dansmith | plus nobody has really looked yet :/ | |
| 14:45:10 | mnaser | your call :) | |
| 14:45:18 | dansmith | mnaser: | |
| 14:45:19 | openstackgerrit | Dan Smith proposed openstack/nova master: Change consecutive build failure limit to a weigher https://review.openstack.org/572195 | |
| 14:46:21 | mnaser | dansmith: awesome, thank you very much for your work on that | |
| 14:46:27 | dansmith | np | |
| 14:54:14 | efried | bauzas, jaypipes: I think https://review.openstack.org/#/c/560459/ is ready when you get a chance. I'm not +2ing because I contributed. | |
| 14:54:24 | bauzas | ok | |
| 15:01:52 | sahid | stephenfin: thanks for the reviex on https://review.openstack.org/#/c/553072/ | |
| 15:04:38 | bauzas | dansmith: just saw https://review.openstack.org/#/c/572195/ | |
| 15:05:09 | bauzas | dansmith: fortunately to https://review.openstack.org/#/c/572195/4/nova/scheduler/host_manager.py, it will work with queens computes | |
| 15:05:35 | stephenfin | sahid: no problem | |
| 15:05:37 | dansmith | bauzas: right that's the point | |
| 15:06:11 | bauzas | dansmith: but https://review.openstack.org/#/c/572195/4/nova/conf/scheduler.py is asking for a default number that's huge | |
| 15:06:33 | dansmith | bauzas: did you read the justification for that number in the commit message? | |
| 15:06:45 | bauzas | sec, I maybe missed it | |
| 15:06:53 | bauzas | if so, my bad | |
| 15:10:06 | dansmith | if it's wrong, please do call it out, but it _was_ an intentional plan :) | |
| 15:10:29 | bauzas | dansmith: /me looking at the related bug to understand the problem | |
| 15:12:23 | dansmith | the first paragraph pretty much sums it up, but the related bug is also good context | |
| 15:14:45 | bauzas | dansmith: humpf, I wasn't knowing https://github.com/openstack/nova/commit/f93f675a :) | |
| 15:15:07 | dansmith | really? okay :) | |
| 15:15:15 | bauzas | yeah, really | |
| 15:15:25 | dansmith | you were in boston, no? | |
| 15:15:44 | bauzas | ok, so now I understand why we want to shuffle computes per number of failed builds | |
| 15:16:06 | bauzas | dansmith: yup, sorry but I don't remember that discussion :( | |
| 15:16:08 | openstackgerrit | Curt Moore proposed openstack/nova-specs master: Add spec for downloading images via RBD https://review.openstack.org/572805 | |
| 15:16:11 | dansmith | okay | |
| 15:16:30 | bauzas | at least, I now understand the problem | |
| 15:21:02 | bauzas | dansmith: in general, we said a couple of times to operators to randomize more the computes by using host_subset_size or shuffle_best_same_weighed_hosts | |
| 15:21:20 | bauzas | dansmith: so that a new instance was asking for a separate compute | |
| 15:21:30 | dansmith | yeah, but people that want strict packing might not want that | |
| 15:21:38 | bauzas | dansmith: agreed | |
| 15:21:45 | jaypipes | efried: done. | |
| 15:21:46 | bauzas | asking to pack is a problem | |
| 15:21:54 | efried | jaypipes: thanks | |
| 15:22:13 | bauzas | dansmith: what I was more thinking was maybe to deprecate one of the two options I mentioned | |
| 15:22:23 | bauzas | dansmith: and recommend using your own weigher | |
| 15:22:47 | bauzas | because once we merge your weigher, we'll get 3 opts for quite the same concern | |
| 15:23:06 | dansmith | um, why? | |
| 15:23:10 | dansmith | I don't think those overlap | |
| 15:23:40 | bauzas | dansmith: I think shuffle_best_same_weighed_hosts overlaps | |
| 15:24:07 | dansmith | with my weigher? | |
| 15:24:20 | bauzas | dansmith: it's two different implementations | |
| 15:24:27 | dansmith | I don't get that | |
| 15:24:38 | bauzas | but at the end, we want to make sure we pack correctly | |
| 15:25:10 | dansmith | without this weigher, hosts that have been failing will be considered at the same score as those that haven't.. shuffle just changes the likelihood you'll land on one of those, modulo the subset size | |
| 15:25:26 | dansmith | with my weigher they're likely not in consideration, moving your chance closer to 100% | |
| 15:26:00 | bauzas | right, that's my point | |