Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-11-30
15:43:10 mdbooth mriedem: They have *some* cash :)
15:43:41 mriedem mnaser: +1 to that
15:44:42 mriedem this might be a shocker, but given our current review rate to bp ratio, i won't hold my breath that this is something we're going to seriously consider soon, especially given we're just now getting deployments upgrading to the big changes we've worked on the last 2 years and they are having problems with them that we're trying to solve
15:44:54 mdbooth mnaser: It looked technically simple enough if we pass a flag in to not boot. I think the change in the libvirt driver, at least, would be relatively small.
15:45:11 mdbooth mriedem: ack. That's exactly why I'm not jumping on this.
15:45:38 mriedem you're talking about the power_on flag right? we use that to keep a stopped vm shutoff during cold migration
15:45:43 mnaser would it? dont we have to shortcircuit the whole: plug port, start up paused, wait for notification, resume thing
15:46:02 mriedem we already have plumbing to not wait for the vif plug if we didn't power on the vm
15:46:10 mnaser ah okay
15:46:17 mriedem it was one of my first big bug fixes in nova
15:47:04 mnaser https://github.com/openstack/nova/commit/9e7c7706a76ad76612ba75314d436a8ba419a3eb
15:47:15 mnaser my amazing nova start
15:48:50 leakypipes :)
15:51:39 mnaser btw
15:51:44 mnaser https://review.openstack.org/#/c/619352/
15:51:44 mnaser we have 2 more releases to go
15:52:09 mnaser not that i run pike but it'd be nice to flush it out
15:59:56 openstackgerrit Matt Riedemann proposed openstack/nova master: Default zero disk flavor to RULE_ADMIN_API in Stein https://review.openstack.org/603910
16:00:54 mriedem mnaser: not sure about your thoughts on a nova-status upgrade check for ^
16:01:14 mriedem to see if (1) you have root_gb=0 flavors and (2) your policy checks out for those
16:01:19 mriedem and dump a warning if not
16:01:52 mriedem i posted to the ML, but likely no one has read it, or grokked it, or cares because they aren't upgraded to that point of caring yet
16:02:47 mriedem checking the policy would be kind of tough though if there is a custom rule configured
16:03:08 mnaser mriedem: i saw it and mentally responded, i should write up a reply
16:03:34 mnaser i'd like to warn against it but also i feel like it might break upgrade tooling in a way
16:03:57 mnaser i guess it's about trying to see it as "behavioural change" vs "bug fix"
16:04:39 mnaser i wouldn't want to see a warning because my cloud is operating as expected.. maybe a warning in stable/rocky though?
16:08:09 openstackgerrit Lee Yarwood proposed openstack/nova stable/queens: compute: Ensure pre-migrating instances are destroyed during init_host https://review.openstack.org/621200
16:08:09 openstack bug 1764883 in OpenStack Compute (nova) "Evacuation fails if the source host returns while the migration is still in progress" [Undecided,Fix released] https://launchpad.net/bugs/1764883 - Assigned to Lee Yarwood (lyarwood)
16:08:09 openstackgerrit Lee Yarwood proposed openstack/nova stable/queens: Add regression test for bug #1764883 https://review.openstack.org/621199
16:12:58 mriedem mnaser: by operating as expected, you mean you have 0 disk flavors but allow non-admins to use them intentionally even if they aren't booting from volume?
16:13:33 mriedem btw, this is another area where https://review.openstack.org/#/c/511965/ would help
16:13:44 openstackgerrit Lee Yarwood proposed openstack/nova stable/pike: Update docs for _destroy_evacuated_instances https://review.openstack.org/621203
16:13:45 openstackgerrit Lee Yarwood proposed openstack/nova stable/pike: compute: Ensure pre-migrating instances are destroyed during init_host https://review.openstack.org/621205
16:13:45 openstack bug 1764883 in OpenStack Compute (nova) "Evacuation fails if the source host returns while the migration is still in progress" [Undecided,Fix released] https://launchpad.net/bugs/1764883 - Assigned to Lee Yarwood (lyarwood)
16:13:45 openstackgerrit Lee Yarwood proposed openstack/nova stable/pike: Add regression test for bug #1764883 https://review.openstack.org/621204
16:14:31 lyarwood temka: ^ there you go
16:16:32 Sundar efried: Please ping me on cyborg channel when you can. Thanks.
16:16:37 mnaser mriedem: sorry, i meant i have 0 disk flavors and i am ok with non-admins no longer being able to boot
16:17:38 temka lyarwood, ack
16:19:02 mriedem mnaser: yeah in my mind the upgrade check wouldn't warn on that - if the policy is the default, you're ok even with 0-disk flavors. i'd think the check would warn if you have 0-disk flavors and your policy was not the default (admin_api)
16:19:13 mriedem but like i said, the policy rule could be custom so it's hard to say
16:19:34 mnaser ah i see what you mean, i could have renamed by admin_api to foo_bar and it would warn anyways
16:19:41 mriedem right
16:19:51 mriedem that's why i'm hesitant to add something
16:20:10 mnaser + if someone is actually running their own policy
16:20:13 mnaser its very likely that its custom anyways
16:22:43 mriedem SteelyDan: before i make this change that leakypipes suggested in my cross-cell resize series, do you agree with it or a meh? https://review.openstack.org/#/c/614012/3/nova/db/sqlalchemy/models.py@794
16:24:58 SteelyDan mriedem: HMM
16:25:00 SteelyDan so,
16:25:17 SteelyDan on the one hand, expanding the schema for a boolean seems kinda silly when we could store something useful
16:25:48 SteelyDan BUT, the migration lives in the cell db, and I don't like ever telling the cell what cell it is, which it can kinda infer from that data
16:26:04 SteelyDan like, imagine you do some migrations and then later collapse or split a cell
16:26:49 mriedem as noted in the change, i get the source cell mapping from the host mapping tied to the source_compute in the migration object https://review.openstack.org/#/c/603930/15/nova/conductor/tasks/cross_cell_migrate.py@871
16:26:56 mriedem so i don't *need* the explicit uuid in the migrations table
16:27:00 SteelyDan right
16:27:07 mriedem the boolean flag is really for flow control
16:27:11 SteelyDan I know
16:27:37 mriedem i don't know if the source/dest cell uuids being in the migration record could be abused later
16:27:50 mriedem i mean, i'm sure they could, i'm just not sure in what case
16:28:21 SteelyDan well, it's not a matter of abuse so much as just separation of responsibilities
16:28:23 mriedem once the migration is done, we shouldn't really care about the record anymore, except reporting
16:28:45 mriedem and if an operator is going to split cells, they had better make sure they don't have migrations going on while doing so
16:29:06 SteelyDan yeah, not a matter of ongoing ones, but just those being wrong later
16:29:24 SteelyDan nothing else in the cell db knows about its position in the hierarchy and I think we should keep it that way
16:29:31 SteelyDan so while I was going to argue against just storing a boolean,
16:29:36 mriedem right. i mean, there could be a comment in there saying, "don't trust these after the migration is done"... but that's a bit hokey
16:29:39 SteelyDan I think I'd prefer that over the uuids just for that reason
16:29:43 SteelyDan heh
16:29:53 mriedem SteelyDan: ok care to reply so i can move on?
16:30:03 SteelyDan yep
16:30:08 mriedem thanks much
16:30:10 mriedem <3
16:38:42 openstackgerrit Corey Bryant proposed openstack/nova stable/pike: Revert "Backport tox.ini to switch to stestr" https://review.openstack.org/621227
17:09:01 openstackgerrit Matt Riedemann proposed openstack/nova master: Add Destination.allow_cross_cell_move field https://review.openstack.org/614035
17:09:01 openstackgerrit Matt Riedemann proposed openstack/nova master: Add Migration.cross_cell_move and get_by_uuid https://review.openstack.org/614012
17:09:02 openstackgerrit Matt Riedemann proposed openstack/nova master: Change HostManager to allow scheduling to other cells https://review.openstack.org/614037
17:09:02 openstackgerrit Matt Riedemann proposed openstack/nova master: Add InstanceAction/Event create() method https://review.openstack.org/614036
17:09:03 openstackgerrit Matt Riedemann proposed openstack/nova master: WIP: Cross-cell resize https://review.openstack.org/603930
17:09:03 openstackgerrit Matt Riedemann proposed openstack/nova master: Add CrossCellWeigher https://review.openstack.org/614353
17:13:35 openstackgerrit Merged openstack/python-novaclient master: Add Python 3.6 classifier to setup.cfg https://review.openstack.org/621093
17:26:41 openstackgerrit Eric Fried proposed openstack/nova master: Reduce calls to placement from _ensure https://review.openstack.org/615677
17:26:42 openstackgerrit Eric Fried proposed openstack/nova master: Commonize _update code path https://review.openstack.org/615705
17:26:42 openstackgerrit Eric Fried proposed openstack/nova master: Consolidate inventory refresh https://review.openstack.org/615695
17:26:43 openstackgerrit Eric Fried proposed openstack/nova master: Rip out the SchedulerClient https://review.openstack.org/617049
17:26:43 openstackgerrit Eric Fried proposed openstack/nova master: Rip the report client out of SchedulerClient https://review.openstack.org/617042
17:26:44 openstackgerrit Eric Fried proposed openstack/nova master: Use a static resource tracker in compute manager https://review.openstack.org/620711
17:26:46 efried leakypipes: This all ought to be ready now ^
17:26:58 leakypipes efried: k
17:28:39 openstackgerrit Eric Fried proposed openstack/nova master: Turn off rp association refresh in nova-next https://review.openstack.org/616033
19:35:18 pacharya Hi I ran into weird issue where nova compute received empty port list for an instance during heal instance info cache. This caused the instance info cache for that instance to be set to empty list and now the APIs are not returning any network information. In the subsequent run neutron returned correct port list but nova does not fix the instance info cache so it remains broken. Any ideas on how to fix this?
19:36:06 SteelyDan mriedem: ^
19:40:21 mriedem pacharya: https://review.openstack.org/#/c/591607/
19:41:19 mriedem without ^ the heal_instance_info_cache and network-changed events just refresh the cache from the cache...which is why it doesn't help you
19:41:42 mriedem unfortunately you need to rebuild the cache somehow, and off the top of my head i think that might mean attaching/detaching a port to/from the server,
19:41:43 mriedem if possible,
19:41:55 mriedem could you just attach a dummy port to the server and then immediately detach it?
19:42:11 mriedem otherwise you might have to try migrating the server, but i'm not sure if that will rebuild the network info cache for the instance
19:44:07 mriedem looking at the code, attaching a new port might just put that port into the cache...
19:44:32 mriedem so i'm not really sure what to tell you beside look at https://review.openstack.org/#/c/591607/

Earlier   Later