| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-05-25 | |||
| 16:40:51 | sdague | the worst thing I think that could happen is if we API (new) create context -> cpu (old) | |
| 16:40:57 | jaypipes | edleafe: you pushed all the ones above that. | |
| 16:40:59 | sdague | then pass it back to something new | |
| 16:41:04 | dansmith | yeah | |
| 16:41:12 | sdague | which means some bits would be lost and fall back to defaults | |
| 16:41:20 | sdague | like global_request_id will end up zeroed out | |
| 16:41:29 | mriedem | sdague: ah you merged it https://review.openstack.org/#/c/466033/ | |
| 16:41:32 | mriedem | so yeah it should be running | |
| 16:41:33 | dansmith | anyway, if we can't want, then I guess we just do it assuming the tests pass, I'm just saying.. there were dragons here last time and I don't know what they all were | |
| 16:41:40 | dansmith | *wait | |
| 16:41:41 | edleafe | Hmmm... I thought when I changed it back it would push that | |
| 16:43:03 | openstackgerrit | Ed Leafe proposed openstack/nova master: Pass the number of hosts to return explicitly https://review.openstack.org/465767 | |
| 16:43:03 | openstackgerrit | Ed Leafe proposed openstack/nova master: Have scheduler claim resources https://review.openstack.org/463993 | |
| 16:43:04 | openstackgerrit | Ed Leafe proposed openstack/nova master: Remove selecting host based on host_subset_size https://review.openstack.org/465174 | |
| 16:43:05 | openstackgerrit | Ed Leafe proposed openstack/nova master: Make the method to put allocations public https://review.openstack.org/464086 | |
| 16:43:06 | openstackgerrit | Ed Leafe proposed openstack/nova master: Don't delete allocation if instance being scheduled https://review.openstack.org/460177 | |
| 16:43:07 | openstackgerrit | Ed Leafe proposed openstack/nova master: Pass a list of instance UUIDs to scheduler https://review.openstack.org/465171 | |
| 16:43:08 | openstackgerrit | Ed Leafe proposed openstack/nova master: Return multiple hosts from select_destinations https://review.openstack.org/465768 | |
| 16:43:15 | sdague | mriedem: yeh, that passed, was there something you were looking for specifically? | |
| 16:43:20 | openstackgerrit | Eric Fried proposed openstack/nova master: PowerVM Driver: SSP emphemeral disk support https://review.openstack.org/443189 | |
| 16:43:29 | edleafe | jaypipes: ^^ ok, I made a small whitespace change to make sure it got pushed | |
| 16:44:49 | sdague | mriedem / dansmith if there is an old bug here I could figure out if that could happen again | |
| 16:45:25 | mriedem | looking | |
| 16:46:09 | jaypipes | edleafe: approved. | |
| 16:46:17 | jaypipes | dansmith: https://review.openstack.org/#/c/464086 is ready for your blessing. | |
| 16:46:39 | sdague | mriedem: I think this was the relevant fix https://review.openstack.org/#/c/341895/ | |
| 16:50:19 | openstack | Launchpad bug 1603979 in OpenStack Compute (nova) "gate: context tests failed because missing parameter "is_admin_project" (oslo.context 2.6.0)" [Critical,Fix released] - Assigned to Tang Chen (tangchen) | |
| 16:50:19 | sdague | https://bugs.launchpad.net/nova/+bug/1603979 is this the bug? | |
| 16:51:06 | sdague | so tonyb's fix is just unit test fixes | |
| 16:51:15 | sdague | it's nothing actually functional | |
| 16:51:24 | sdague | https://review.openstack.org/#/c/342604/ | |
| 16:51:45 | dansmith | the thing I'm talking about was identified before we bumped the version in u-c | |
| 16:51:53 | dansmith | so probably not that bug | |
| 16:52:01 | mriedem | http://logs.openstack.org/95/467995/3/check/gate-grenade-dsvm-neutron-multinode-live-migration-nv/46deb21/logs/new/tempest_conf.txt.gz | |
| 16:52:04 | mriedem | live_migrate_back_and_forth = True | |
| 16:52:05 | dansmith | anyway, if you guys are confident and see tests, then just do it | |
| 16:52:29 | sdague | dansmith: ok, I'm having a hard time finding any reference to what that was | |
| 16:52:49 | dansmith | sdague: my major involvement was a hallway conversation and shared laptop screen with tonyb | |
| 16:53:53 | sdague | this would have been midcycle? http://lists.openstack.org/pipermail/openstack-dev/2016-July/099467.html | |
| 16:54:00 | mriedem | it might have also been some capped requirement crap | |
| 16:54:03 | mriedem | in stable | |
| 16:54:07 | sdague | because the dates for the unit test break are all around this | |
| 16:54:15 | mriedem | yes newton midcycle | |
| 16:54:25 | sdague | right, so that was entirely about unit tests | |
| 16:54:38 | mriedem | confirmed that we're doing the back and forth live migration in that grenade job http://logs.openstack.org/95/467995/3/check/gate-grenade-dsvm-neutron-multinode-live-migration-nv/46deb21/logs/tempest.txt.gz#_2017-05-25_15_16_25_895 | |
| 16:54:41 | mriedem | so we should be happy | |
| 16:54:50 | sdague | actually these same unit tests blocking the the current oslo.context uc bump | |
| 16:55:10 | edleafe | jaypipes: running out for a bit. I'll answer any other questions when I get back. | |
| 16:55:14 | sdague | mriedem: cool | |
| 16:55:15 | mriedem | +2 | |
| 16:57:56 | sdague | mriedem: great | |
| 16:58:14 | sdague | ok, need another +2 to unblock uc | |
| 17:00:48 | mriedem | i need a plate of food to unblock my hunger | |
| 17:01:58 | mriedem | +2 on the spec also | |
| 17:06:44 | cfriesen | for upgrading from newton (without any cells) to ocata, what nova-manage commands are needed prior to the migration? I think it's "nova-manage cell_v2 simple_cell_setup", "nova-manage db sync", "nova-manage api-db sync", and "nova-manage db online_data_migrations". Am I missing anything? (And when would you use "nova-manage cell_v2 map_cell0" instead?) | |
| 17:07:17 | cfriesen | I'm looking at the upgrade notes and some of the cellsv2 stuff is a bit ambiguous | |
| 17:09:19 | cuhler | Hi mriedem, os-brick version has been bumped (incl global-requirements here: https://review.openstack.org/#/c/467757/). Can you please remove the workflow -1 and review Veritas nova volume driver at https://review.openstack.org/#/c/443951/? Thx. | |
| 17:11:39 | mriedem | cfriesen: https://docs.openstack.org/developer/nova/cells.html#upgrade-minimal | |
| 17:11:48 | mriedem | https://docs.openstack.org/developer/nova/man/nova-manage.html#nova-cells-v2 | |
| 17:11:55 | mriedem | https://docs.openstack.org/developer/nova/cells.html#faqs | |
| 17:12:06 | mriedem | cuhler: sure | |
| 17:12:26 | cfriesen | mriedem: thanks | |
| 17:12:47 | sdague | mriedem: great | |
| 17:15:00 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Libvirt volume driver for Veritas HyperScale https://review.openstack.org/443951 | |
| 17:15:25 | mriedem | cuhler: +2 | |
| 17:15:42 | mriedem | now you must fish for another core | |
| 17:16:35 | cfriesen | mriedem: re the point about newton expecting a different name for the cell0 database...does that cause problems when later upgrading to ocata? | |
| 17:17:11 | mriedem | cfriesen: have you created a cell0 db yet? | |
| 17:17:15 | mriedem | and if so, what did you name it? | |
| 17:17:28 | cfriesen | nope...planning on holding off till the ocata upgrade if I can | |
| 17:17:43 | cfriesen | I'm just trying to figure out what I should do after upgrading to newton | |
| 17:17:48 | mriedem | ok, if you're running the nova-manage commands from ocata code you'll be fine | |
| 17:18:03 | cfriesen | cool, will hold off then | |
| 17:18:20 | mriedem | need to get https://review.openstack.org/#/c/420461/ into newton, along with it's dependencies | |
| 17:18:27 | mriedem | sdague: ^ could you poke through those? | |
| 17:18:36 | mriedem | there is a dependent grenade and devstack backport in there | |
| 17:20:47 | sdague | looking | |
| 17:23:32 | cuhler | mriedem: thanks | |
| 17:24:03 | sdague | mriedem: lgtm | |
| 17:28:06 | mriedem | thanks | |
| 17:28:24 | mriedem | dansmith: this is going to need your loving care https://review.openstack.org/#/c/420461/ - that's the newton backport to fix the default cell0 db name connection string we talked about yesterday | |
| 17:30:20 | mriedem | melwitt: do you want me to hold off on https://review.openstack.org/#/c/446239/ for now? | |
| 17:31:25 | mriedem | melwitt: we could probably do facade thing for count() in the object code in a separate cleanup if we want to move forward | |
| 17:32:28 | melwitt | mriedem: I was gonna wait until you were done with the tests to update anything to get them all at once. but, if I remove count() from nova/quota then I need to add a test for the facade thing in nova/objects/quotas. so it's up to you, want me to update it first and then you look again? | |
| 17:32:42 | mriedem | let me skim the tests first | |
| 17:33:06 | melwitt | k. I'm just running through the facade change locally to make sure things don't break | |
| 17:39:48 | mriedem | melwitt: why is test_reservation_expire removed? | |
| 17:40:15 | melwitt | mriedem: gah, I meant to put that back. accidental removal | |
| 17:40:22 | mriedem | ok, i'll leave a reminder | |
| 17:40:26 | melwitt | thanks | |
| 17:47:35 | savvas | mriedem: I noticed your fingerprints on https://blueprints.launchpad.net/nova/+spec/flavor-root-disk-none . Is there a best practice suggestion to secure this? For example I am bypassing the quota limitation on my local disks by removing the DiskFilter filter from nova (which is far from ideal..) but I have no way to enforce instances being created with use of cinder volumes instead of local block devices. | |
| 17:51:24 | savvas | I found this in nova.conf: max_local_block_devices but again this would not be ideal as reading the comments suggests that it won't pick alternative storage instead. | |
| 17:53:10 | mriedem | savvas: max_local_block_devices isn't what you think it is | |
| 17:53:29 | mriedem | savvas: otherwise i don't think there is a way to force users to boot from volume | |
| 17:53:45 | mriedem | let me find something for you to read | |
| 17:54:01 | mriedem | savvas: http://lists.openstack.org/pipermail/openstack-dev/2017-May/117012.html | |
| 17:56:40 | openstackgerrit | Dan Smith proposed openstack/nova master: re-Allow adding computes with no ComputeNodes to aggregates https://review.openstack.org/460616 | |
| 17:59:09 | mriedem | melwitt: ok comments posted | |
| 18:00:07 | melwitt | mriedem: thanks, looking | |
| 18:03:52 | savvas | mriedem: interesting. So at this time there is no way to bypass/secure this limitation in the software? | |