| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-09-01 | |||
| 16:54:56 | dansmith | and when build finishes it'll replace the doubled (due to migration) allocation with the single one for the new host | |
| 16:54:59 | mriedem | the instance wouldn't necessarily be in ERROR state, | |
| 16:55:08 | dansmith | it would from that novalidhost | |
| 16:55:08 | mriedem | and conductor doesn't set it to ERROR state if it fails to find a host | |
| 16:55:12 | mriedem | nope | |
| 16:55:17 | mriedem | it just resets the task_state to None | |
| 16:55:18 | dansmith | it does _set_vm_state_and_notify() | |
| 16:55:29 | mriedem | self._set_vm_state_and_notify(context, instance.uuid, | |
| 16:55:30 | mriedem | 'task_state': None}, ex, request_spec) | |
| 16:55:30 | mriedem | {'vm_state': instance.vm_state, | |
| 16:55:30 | mriedem | 'rebuild_server', | |
| 16:55:34 | mriedem | i've been all up in this code for a week | |
| 16:55:35 | dansmith | oh, does that not set it to error? | |
| 16:55:38 | mriedem | nope | |
| 16:55:40 | dansmith | I see | |
| 16:55:46 | dansmith | well a reset state will put it in error | |
| 16:55:52 | mriedem | if you tell it to :) | |
| 16:56:00 | mriedem | reset-state takes the state you want it in | |
| 16:56:01 | mriedem | i htink | |
| 16:56:04 | dansmith | doesn't reset state default to error? | |
| 16:56:11 | dansmith | no, it's just error or --active as an option I think | |
| 16:56:34 | mriedem | oh i don't know what the CLI does | |
| 16:56:37 | mriedem | but the API doesn't default | |
| 16:56:40 | mriedem | "The state of the server to be set, active or error are valid." | |
| 16:56:55 | dansmith | well, sure | |
| 16:57:10 | mriedem | yeah default on the CLI is 'error' | |
| 16:57:38 | dansmith | I guess we could make it go to error state in here as a change if you think that's better | |
| 16:57:51 | dansmith | I think that won't affect rebuilds because we don't schedule if we do a rebuild, but do for evac | |
| 16:58:02 | mriedem | right we bypass the scheduler for rebuild | |
| 16:59:05 | mriedem | so yeah we could set the instance to ERROR state in conductor... | |
| 16:59:17 | mriedem | if it's an evac | |
| 16:59:20 | mriedem | *failed evac | |
| 17:01:31 | mriedem | well, now i'm not sure what to do | |
| 17:03:15 | dansmith | have a beer? | |
| 17:05:40 | mriedem | i left a summary in https://review.openstack.org/#/c/499237/ | |
| 17:05:52 | mriedem | feel free to r'ar or whatever | |
| 17:05:56 | mriedem | i'm going to make lunch | |
| 17:58:37 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Update docs for _destroy_evacuated_instance https://review.openstack.org/500144 | |
| 18:03:28 | openstackgerrit | Sean Dague proposed openstack/nova master: DNM: test cells v1/nova-net without screen https://review.openstack.org/500151 | |
| 18:03:42 | sdague | mriedem: doesn't seem like cellsv1 job is even in experimental queue for devstack? | |
| 18:04:26 | mriedem | it should be | |
| 18:04:45 | mriedem | used to be anyway | |
| 18:05:26 | mriedem | but yeah i don't see it in there now | |
| 18:06:01 | mriedem | only in experimental for tempest and nova from what i see | |
| 18:09:16 | mriedem | sdague: are you going to add that or should i? | |
| 18:10:16 | openstackgerrit | Matt Riedemann proposed openstack/nova master: doc: link to versioned notification samples from main index https://review.openstack.org/500081 | |
| 18:10:16 | openstackgerrit | Matt Riedemann proposed openstack/nova master: doc: link to placement api-ref and history docs from main index https://review.openstack.org/498977 | |
| 18:26:12 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Modernize set_vm_state_and_notify https://review.openstack.org/499799 | |
| 18:26:12 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Remove dest node allocation if evacuate MoveClaim fails https://review.openstack.org/499878 | |
| 18:28:10 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Update docs for _destroy_evacuated_instances https://review.openstack.org/500144 | |
| 18:28:10 | fried_rice | Procedural question: can I repoint the spec link for a blueprint? Need to submit a q spec for https://blueprints.launchpad.net/nova/+spec/use-service-catalog-for-endpoints | |
| 18:29:11 | mriedem | fried_rice: i have edit rights | |
| 18:29:13 | mriedem | so i can | |
| 18:29:26 | fried_rice | mriedem Ah, cool. So I'll shoot ya the link once I have it. Thanks. | |
| 18:30:42 | openstackgerrit | Merged openstack/nova stable/pike: Fix nova assisted volume snapshots https://review.openstack.org/498979 | |
| 18:31:02 | mriedem | thanks for making me think of this https://www.youtube.com/watch?v=GP1KHL0j0GU | |
| 18:40:05 | sdague | mriedem: either way, I was just surprised. I feel like we had this issue before | |
| 18:40:56 | mriedem | sdague: it comes up every time a devstack change breaks the cells v1 job and blocks nova | |
| 18:41:13 | mriedem | then we fix whatever and forget about it | |
| 18:47:00 | fried_rice | mriedem So the other thing is, this is no longer going to be "use service catalog for endpoints" - it's going to be "use keystoneauth1 discovery for endpoints". Can the blueprint-identifying name be changed; or do I need to file a new blueprint; or do we not care that the identifier is out of sync? | |
| 18:47:03 | sdague | ok, I really thought we merged it the last time :) | |
| 18:49:06 | mriedem | fried_rice: changing the bp name in lp would break the link in the old spec | |
| 18:49:09 | sdague | mriedem: https://review.openstack.org/500169 | |
| 18:49:14 | mriedem | we could file a new blueprint and supersede the old one | |
| 18:49:32 | fried_rice | mriedem Okay, I'll do that. Thanks. | |
| 18:49:43 | fried_rice | long as there's a backtrail. | |
| 18:49:48 | fried_rice | supersede works | |
| 18:50:37 | mriedem | sdague: +1 | |
| 18:51:23 | mriedem | dansmith: superdan: sdague: btw, i'm huawei now but guess what i get to do | |
| 18:51:24 | mriedem | BCG | |
| 18:51:34 | mriedem | jealous!? | |
| 18:51:47 | dansmith | wooooo | |
| 19:03:38 | mriedem | but no videos... | |
| 19:03:39 | mriedem | :( | |
| 19:04:15 | mriedem | "what do you think? should wanda record the future sale to her friend's sister's government contractor for the 3rd quarter even though the sale isn't complete but they say they will sign?" | |
| 19:04:28 | mriedem | ....YES! | |
| 19:09:12 | sdague | mriedem: ok, well at least one cells incompat found and fixed, I'll see if that gets it to completion | |
| 19:28:54 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Pass migration from API to conductor for evacuate https://review.openstack.org/500176 | |
| 20:45:44 | cdent | mriedem: I recall from earlier in the week there was stuff happening about placement-osc-plugin. Where did that end up? Still in progress? Stall? Abort? Done? | |
| 20:45:54 | openstackgerrit | Eric Fried proposed openstack/nova-specs master: Spec: Use keystoneauth1 Adapter for endpoints https://review.openstack.org/500190 | |
| 20:46:34 | fried_rice | mriedem mordred sdague ^ kablam | |
| 21:46:04 | prometheanfire | looks like online_data_migrations are broken in pike for postgresql | |
| 21:47:06 | prometheanfire | mriedem: http://paste.openstack.org/show/h1ABPkHTtlL8i29IIF3i/ | |
| 21:47:25 | prometheanfire | that's after a db sync (which was successful) | |
| 21:49:33 | prometheanfire | http://paste.openstack.org/show/Oen7ZwvnFNlHfjSXyx9S/ has a second/third run too | |
| 21:54:07 | cdent | prometheanfire: is this actually true: “column build_requests.tags does not exist”? | |
| 21:55:36 | prometheanfire | which table? | |
| 21:55:53 | prometheanfire | guess build_requests? | |
| 21:56:26 | prometheanfire | that table is absent | |
| 21:56:28 | cdent | that’s nova/db/sqlalchemy/api_migrations/migrate_repo/versions/042_build_requests_add_tags.py | |
| 21:57:06 | cdent | diid you sync both all your databases? | |
| 21:57:23 | prometheanfire | that may be it | |
| 21:57:24 | prometheanfire | ... | |
| 21:57:42 | cdent | you need an api_db sync too | |
| 21:57:55 | prometheanfire | ya, I forget that every time | |
| 21:58:01 | cdent | :( it ought to be simpler | |
| 21:58:37 | prometheanfire | yep, happier now, NOTABUG | |
| 21:58:48 | prometheanfire | :D | |
| 21:59:00 | prometheanfire | so far so good this time around with postgres | |
| 21:59:15 | cdent | I was actually kind of hoping that it was a bug so we could have the “is postgres supported _really_?” argument all over again | |