| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-10-19 | |||
| 18:59:53 | mriedem | maybe i'll restore and rev that to clean it up | |
| 19:00:05 | mriedem | on top of https://review.openstack.org/#/c/597553/ | |
| 19:19:50 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Log the operation when updating generation in ProviderTree https://review.openstack.org/597553 | |
| 19:19:51 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add debug logs for when provider inventory changes https://review.openstack.org/597560 | |
| 19:29:28 | mriedem | melwitt: https://bugs.launchpad.net/nova/+bug/1798787 | |
| 19:29:29 | openstack | Launchpad bug 1798787 in OpenStack Compute (nova) "Installation help documentation is incorrect - verify & nova-consoleauth" [Medium,Triaged] | |
| 19:30:26 | mriedem | the install guide tells you to verify nova-consoleauth is running but we don't tell you to install/start it | |
| 19:30:30 | mriedem | b/c that part was removed in rocky | |
| 19:31:05 | melwitt | gah | |
| 19:32:14 | cdent | Is there a bug that is associated with provider tree cache problems discussed above? | |
| 19:32:23 | mriedem | cdent: not that i'm aware of | |
| 19:32:31 | mriedem | i think awaugama hit it in QE | |
| 19:33:02 | awaugama | yeah verifying vcpu weighter feature | |
| 19:33:22 | cdent | awaugama: are you making a bug? If so I want to be sure to follow along | |
| 19:33:57 | awaugama | cdent, I will next week. I need to reinstall my system (did another feature test in the meantime) so I'll need to recollect logs | |
| 19:34:08 | mriedem | is this a tripleo system that takes 3 days? | |
| 19:34:17 | SteelyDan | heh | |
| 19:34:26 | cdent | great, thanks awaugama | |
| 19:34:55 | mriedem | btw, speaking of tripleo | |
| 19:34:55 | awaugama | mriedem: I can probably get it repro'd by EOD Tuesday | |
| 19:34:57 | awaugama | but yeah | |
| 19:35:24 | mriedem | who from the red hat nova cabal can add nova-status upgrade check to tripleo? | |
| 19:35:36 | mriedem | owalsh: ^? | |
| 19:35:42 | SteelyDan | or mschuppert | |
| 19:36:04 | awaugama | yeah one of those two is the nova deployment guy | |
| 19:36:52 | awaugama | their specialty is based on the need | |
| 19:38:08 | openstackgerrit | Elod Illes proposed openstack/nova master: Transform scheduler.select_destinations notification https://review.openstack.org/508506 | |
| 19:38:25 | sean-k-mooney | awaugama: and the fact that everyone else avoid using tripleo to deploy our dev envs if we can | |
| 19:41:13 | awaugama | fair enough | |
| 19:41:35 | mriedem | SteelyDan: oooo guess what just rotated in https://www.youtube.com/watch?v=jJ9Xk-VoGqo | |
| 19:41:41 | SteelyDan | nice | |
| 19:42:16 | SteelyDan | I enjoyed when this rotated in for me this morning: https://www.youtube.com/watch?v=KCdKBHdPz30 | |
| 19:43:20 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/rocky: Don't persist RequestSpec.requested_destination https://review.openstack.org/611939 | |
| 19:43:20 | openstack | bug 1797580 in OpenStack Compute (nova) "NoValidHost during live migration after cold migrating to a specified host" [High,In progress] https://launchpad.net/bugs/1797580 - Assigned to Matt Riedemann (mriedem) | |
| 19:43:20 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/rocky: Add regression test for bug 1797580 https://review.openstack.org/611938 | |
| 19:44:08 | mriedem | i know i'd never do it without the fez on | |
| 19:44:14 | openstackgerrit | Dan Smith proposed openstack/nova master: Minimal construct plumbing for nova list when a cell is down https://review.openstack.org/567785 | |
| 19:44:14 | openstackgerrit | Dan Smith proposed openstack/nova master: Modify get_by_cell_and_project() to get_not_deleted_by_cell_and_projects() https://review.openstack.org/607663 | |
| 19:44:15 | openstackgerrit | Dan Smith proposed openstack/nova master: Return a minimal construct for nova show when a cell is down https://review.openstack.org/591658 | |
| 19:44:15 | openstackgerrit | Dan Smith proposed openstack/nova master: Refactor scatter-gather utility to return exception objects https://review.openstack.org/607934 | |
| 19:44:16 | openstackgerrit | Dan Smith proposed openstack/nova master: Return a minimal construct for nova service-list when a cell is down https://review.openstack.org/584829 | |
| 19:44:18 | SteelyDan | heck no | |
| 19:44:50 | melwitt | never heard of either of those. I only know the major steely dan hits | |
| 19:45:13 | mriedem | kid charlemagne is a major hit | |
| 19:45:17 | mriedem | all the major dudes know that | |
| 19:45:18 | SteelyDan | well, | |
| 19:45:28 | SteelyDan | she probably means like reelin' in the years and rikki | |
| 19:45:29 | melwitt | major dudes?? | |
| 19:45:31 | SteelyDan | and dirty work | |
| 19:45:39 | melwitt | yeah and like NO STATIC AT ALLLL | |
| 19:45:41 | mriedem | https://www.youtube.com/watch?v=kND8TRZap8Y | |
| 19:45:53 | SteelyDan | like floyd, the major hits are not very representative of the larger work | |
| 19:45:56 | melwitt | and hey nineteen | |
| 19:46:05 | melwitt | and deacon blues | |
| 19:46:40 | melwitt | lol, of course it was a reference to another song I don't know | |
| 19:47:12 | mriedem | when the sax solo from FM comes on in the car, i always yell at the girls to quit down and crank it way up | |
| 19:47:16 | mriedem | obnoxiously so | |
| 19:47:24 | mriedem | *quiet | |
| 19:47:30 | SteelyDan | heh | |
| 19:47:33 | melwitt | as one does | |
| 19:47:54 | sean-k-mooney | mriedem: oh i actully have heard the last link you posted before | |
| 19:55:28 | openstack | bug 1797580 in OpenStack Compute (nova) rocky "NoValidHost during live migration after cold migrating to a specified host" [High,In progress] https://launchpad.net/bugs/1797580 - Assigned to Matt Riedemann (mriedem) | |
| 19:55:28 | openstackgerrit | Merged openstack/nova master: Add regression test for bug 1797580 https://review.openstack.org/610088 | |
| 19:56:13 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/queens: Add regression test for bug 1797580 https://review.openstack.org/611944 | |
| 19:56:14 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/queens: Don't persist RequestSpec.requested_destination https://review.openstack.org/611945 | |
| 19:57:17 | mriedem | SteelyDan: remember this? https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L4310 | |
| 19:57:50 | melwitt | wah wah | |
| 19:57:54 | mriedem | it's pretty safe to assume that all cold/live migrations are migration-based allocations now right? | |
| 19:58:01 | mriedem | b/c that was added to compute in queens | |
| 19:58:25 | mriedem | i'm wondering if we can start rolling those compat shims back, including https://github.com/openstack/nova/blob/master/nova/conductor/tasks/migrate.py#L102 | |
| 19:58:33 | mriedem | and just assume compute is new enough to always send a migration record | |
| 19:58:41 | mriedem | and do that hot swap action | |
| 19:59:07 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Use oslo_db.sqlalchemy.test_fixtures https://review.openstack.org/609352 | |
| 19:59:24 | mriedem | i think that's also safe because of https://github.com/openstack/nova/blob/master/nova/compute/rpcapi.py#L716 | |
| 19:59:26 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (3) https://review.openstack.org/574104 | |
| 19:59:29 | mriedem | we're unconditionally sending the migration record | |
| 19:59:44 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (4) https://review.openstack.org/574106 | |
| 19:59:45 | SteelyDan | mriedem: yeah | |
| 19:59:51 | SteelyDan | mriedem: I leave those TODOs for others | |
| 19:59:57 | mriedem | tl;dr i would like to rip that code out before landing gibi's https://review.openstack.org/#/c/606050/ which breaks resize to same host allocatoins if we don't have the source allocations on the migration record | |
| 20:00:02 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (5) https://review.openstack.org/574110 | |
| 20:00:16 | mriedem | ok cool | |
| 20:00:26 | mriedem | the other thing with that was caching scheduler which is also queued up for death | |
| 20:00:34 | melwitt | that would be a funny TODO. "TODO(dan): Other people remove this in Rocky" | |
| 20:00:44 | mriedem | SteelyDan: i have ont yet | |
| 20:00:45 | SteelyDan | melwitt: next time. I promise. | |
| 20:00:45 | mriedem | *not yet | |
| 20:00:53 | melwitt | awesome | |
| 20:01:06 | SteelyDan | whoa, errant /me in there, sorry | |
| 20:03:03 | cfriesen | ephemeral disks are supposed to last the life of the instance, right? | |
| 20:03:49 | openstackgerrit | Merged openstack/nova master: Don't persist RequestSpec.requested_destination https://review.openstack.org/610098 | |
| 20:04:46 | sean-k-mooney | cfriesen: yes and know | |
| 20:05:04 | sean-k-mooney | cfriesen: i dont know if they are ment to be copied if we move the guest or not | |
| 20:05:31 | sean-k-mooney | cfriesen: they are ment to exsits for the life of an insntace on a singel host definetly. | |
| 20:06:14 | sean-k-mooney | cfriesen: resize is totally undefiend what happens. live/coldmigrate i think we copy them but havent checked that is just my intuition | |
| 20:07:13 | sean-k-mooney | cfriesen: similarly for shelve unshelve not sure we persit tiem. it might be driver specific | |
| 20:07:55 | cfriesen | sean-k-mooney: hmm...I think this wording in the compute API has changed since I looked at it: "Ephemeral disks may be written over on server state changes. So should only be used as a scratch space for applications that are aware of its limitations." | |
| 20:09:18 | sean-k-mooney | cfriesen: ya root disk will be perserved obviourly but adtionl epheral disk i think its totally up to the driver on what state chages they are preserved and when they are recreated | |
| 20:09:37 | SteelyDan | sean-k-mooney: I don't think any of those things are right | |
| 20:09:59 | SteelyDan | I don't think it's well defined at all, but the original assumption was that you couldn't even rely on them across start/stop cycles on your instance | |