| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-06-28 | |||
| 15:06:51 | mriedem | i.e. https://review.opendev.org/#/c/656885/ | |
| 15:07:19 | mriedem | that's been kicked around for many years and is going to be complicated i imagine | |
| 15:07:42 | mriedem | we don't even have integration testing for the routed networks support that is documented in the neutron docs | |
| 15:08:08 | mriedem | https://docs.openstack.org/neutron/latest/admin/config-routed-networks.html | |
| 15:08:11 | sean-k-mooney | i think they also wanted to supprot using sharing aggrates to model things like floating ips and what host can recive an ip form which subnet pool | |
| 15:08:44 | mriedem | well the good news is pop up teams officially exist now so all of this work can get done! | |
| 15:09:14 | sean-k-mooney | ya without a cross project effort this is hard to make progress on | |
| 15:09:52 | mriedem | i was being a sarcastic jerk but yeah | |
| 15:11:09 | sean-k-mooney | hehe well i have tried to do enough stuff that crosses the nova neutron boundry that i know without getting buyin form both core teams up front and finding people to care about it it will fail | |
| 15:11:33 | sean-k-mooney | anyway thats a tangent | |
| 15:11:56 | mriedem | lyarwood: i guess you got busy https://review.opendev.org/#/q/topic:bug/1653953+(status:open+OR+status:merged) | |
| 15:13:11 | lyarwood | mriedem: busy spamming yes, hopefully that's what you had in mind. | |
| 15:13:24 | mriedem | it is | |
| 15:14:01 | lyarwood | wonderful, there are also DNM changes actually testing things on each branch btw | |
| 15:14:08 | lyarwood | I'll add them to the same topic now to make it clear | |
| 15:14:45 | mriedem | oh i see | |
| 15:15:05 | mriedem | nova DNM changes that depend on the related devstack-plugin-ceph change per branch that depeds on the backport per nova branch.... | |
| 15:15:28 | lyarwood | and around and around we go | |
| 15:16:08 | lyarwood | but that should allow the fix to land then the change to enable the test without everything blowing up like it did with my cinder migrate series. | |
| 15:16:08 | mriedem | this is going to be a pain for cross-cell resize, i'm not sure how i'm going to handle that | |
| 15:17:37 | lyarwood | I really need to go over the spec and code for that, are you using shelve/unshelve there? | |
| 15:17:44 | mriedem | no, | |
| 15:18:02 | mriedem | but for non-volume-backed servers, like shelve i'm creating a snapshot to get the disk from the source cell to the target cell | |
| 15:18:16 | mriedem | and then spawning from that snapshot in the target cell and then delete the temporary snapshot, like unshelve | |
| 15:18:32 | mriedem | so the fix here about checking the vm_state wont' work for cross-cell resize | |
| 15:19:26 | lyarwood | yeah true | |
| 15:19:30 | mriedem | we could check something like the task_state used during that part of the cross-cell resize spawn, but that's going to be used during a normal resize as well, and i'm not sure if flatten should be used there | |
| 15:19:45 | mriedem | we could temporarily hack something into the image meta or the instance system_metadata to be read by the driver, but again that's super hacky | |
| 15:19:59 | lyarwood | You could make it optional for resize and spawn tbh | |
| 15:20:14 | mriedem | optional how? | |
| 15:20:44 | lyarwood | with a configurable, but it would slightly slow down spawns and resizes etc in any env that used it | |
| 15:20:54 | lyarwood | so maybe not | |
| 15:20:59 | mriedem | i think i know a bit better solution, | |
| 15:21:20 | mriedem | the instance.migration_context should be set during a cross-cell resize, and from that we can get the Migration record which will have a cross_cell_move boolean on it so i'd just check that | |
| 15:21:22 | mriedem | from the driver | |
| 15:21:54 | mriedem | it's not fun but it's better than driver interface changes or hacking metadata temporarily or checking vm/task state | |
| 15:22:12 | lyarwood | ack that works | |
| 15:22:36 | lyarwood | we don't have a migration record for shelve/unshelve right? | |
| 15:22:49 | lyarwood | IOW I haven't missed an easier way of fixing my issue? | |
| 15:23:19 | lyarwood | ignore me, of course we don't. | |
| 15:23:20 | mriedem | nope | |
| 15:24:33 | dansmith | that's interesting, | |
| 15:24:36 | dansmith | I've never thought about that | |
| 15:25:01 | dansmith | a migration record would let us provide some unshelve (whilst offloaded) host affinity | |
| 15:25:14 | dansmith | not sure how important that is really, but... | |
| 15:25:59 | efried | dansmith, mriedem: How do y'all feel about reorganizing how request filters are enabled via conf? | |
| 15:25:59 | efried | As it stands, it looks like we're headed for random options scattered around various groups. | |
| 15:25:59 | efried | Wondering if it would make sense e.g. to collect them into [request_filter] $name = {enabled|disabled} | |
| 15:25:59 | efried | or [scheduler] request_filters_enabled = $name[,...] | |
| 15:25:59 | efried | or ... | |
| 15:25:59 | efried | My hesitation is that that's really more of a dev-oriented structure; I don't know that the filters are really similar enough in spirit that that would make sense to the operator. | |
| 15:25:59 | efried | Thoughts? | |
| 15:26:11 | mriedem | dansmith: what do you mean? unshelve back to the original host? | |
| 15:26:39 | dansmith | efried: I think we should aim for enabling behaviors not filters | |
| 15:26:48 | dansmith | efried: and we should aim for most of those to be always on by default | |
| 15:27:17 | mriedem | i'd like to avoid a list like enabled_filters | |
| 15:27:27 | dansmith | yeah | |
| 15:28:03 | dansmith | people enable or disable filters based on name, without really knowing that their behavior can be composite of multiple things | |
| 15:28:43 | efried | okay, that's kind of where my head was going, thanks for the validation. | |
| 15:30:05 | dansmith | mriedem: yes, for unshelve affinity back to the original host, after offload | |
| 15:30:23 | mriedem | dansmith: we save off the original host in system_metadata | |
| 15:30:38 | dansmith | oh, do we? | |
| 15:30:58 | mriedem | https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L5112 | |
| 15:31:21 | dansmith | okay | |
| 15:31:51 | dansmith | a migration record would make that a little less special-to-shelve-y and more a record of the move | |
| 15:31:58 | dansmith | but anyway, just hadn't thought about it before | |
| 15:32:27 | mriedem | yeah i'm not sure how much it matters either, | |
| 15:32:33 | mriedem | the original host could be gone by the time you unshelve | |
| 15:32:43 | dansmith | sure, it'd just be a weight thing | |
| 15:32:50 | mriedem | right, was just going to say that, | |
| 15:32:54 | mriedem | pass a weight hint to the scheduler | |
| 15:32:58 | mriedem | if you can, do else no biggy | |
| 15:33:02 | dansmith | right | |
| 15:33:12 | dansmith | in "edge" cases, | |
| 15:33:29 | dansmith | where you have two boxes at a site that are largely for hosting specific types of things, | |
| 15:33:42 | dansmith | you'd have better image affinity | |
| 15:34:02 | dansmith | if you're enforcing it then it doesn't matter | |
| 15:34:08 | dansmith | anyway, | |
| 15:34:45 | dansmith | just a thought that shelve could be more of a move for harmony with the other ops | |
| 15:44:07 | openstackgerrit | Eric Fried proposed openstack/nova master: Support filtering of hosts by forbidden aggregates https://review.opendev.org/667952 | |
| 15:46:59 | efried | donnyd: Yo Mr. Docs, would you mind giving this a scan and seeing if it makes sense to you with your operator hat on? https://review.opendev.org/#/c/667952/2/doc/source/reference/forbidden-aggregates.rst | |
| 15:47:54 | efried | mriedem: btw, that's what all those handy dandy CLIs were for ^ | |
| 15:50:35 | mriedem | jesus that is a large patch, | |
| 15:50:38 | mriedem | can that be split up? | |
| 15:50:48 | donnyd | It reads fine to me. I would just use the same terminology everywhere. we call the function host-aggregate, so when referring to aggregate i would sub for host-aggregate | |
| 15:50:56 | donnyd | or whatever the proper term is | |
| 15:52:25 | mriedem | maybe it's mostly testing and docs... | |
| 15:52:27 | efried | mriedem: It could maybe be split up, but it would be kind of contrived. It's pretty easy to read imo | |
| 15:52:28 | efried | yes. | |
| 15:53:24 | donnyd | Yea, i had no issue at all understanding what is trying to be conveyed | |
| 15:53:33 | efried | donnyd: Thanks for the look. I actually don't know what the accepted term is, I probbaly flubbed several of those. | |
| 15:54:03 | efried | donnyd: (mriedem was talking about the patch as a whole, not specifically the doc) | |
| 15:54:38 | efried | I'll just go on record as saying I think this is a pretty darn cool feature. | |
| 15:55:20 | efried | Considering how weird and complex the implementation is, the external-facing usage model is pretty slick. | |
| 15:56:04 | efried | the most effed up part is how you have to collect the existing traits before you can add the one you want to the host :P | |
| 15:56:22 | efried | ...which of course has nothing to do with the forbidden aggregates feature. | |
| 15:57:43 | dansmith | is this already merged? | |
| 15:57:48 | mriedem | ok ok you win, we can add the PUT /resource_providers/{uuid}/traits/{trait_name} you've always wanted | |
| 15:58:03 | dansmith | I'm confused about how you get the exclusion just because one flavor is tagged | |
| 15:58:10 | mriedem | just like this fine mess https://developer.openstack.org/api-ref/compute/#server-metadata-servers-metadata | |