| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-05-25 | |||
| 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? | |
| 18:05:23 | mriedem | savvas: i'm not aware of one outside of patches people have put into their systems | |
| 18:06:09 | mriedem | savvas: the outcome of that session was to write a spec for the short-term solution to auto-create block device mappings based on the flavor (which the operator controls) if bdms aren't requested by the user | |
| 18:06:20 | mriedem | not using extra specs | |
| 18:06:37 | savvas | ye the short term solution sounds acceptable though | |
| 18:06:59 | mriedem | says the guy that wants *anything* | |
| 18:07:02 | mriedem | :) | |
| 18:07:13 | mriedem | that's all queens release at this point | |
| 18:07:34 | jaypipes | mriedem, dansmith: if you have time. https://review.openstack.org/#/c/461574/ | |
| 18:07:41 | savvas | hehe, ye ;> | |
| 18:08:36 | mriedem | jaypipes: didn't you need an os-traits release and g-r bump for something in this series? | |
| 18:08:45 | savvas | basically it menas if we end up selling a project based solution, at this point having api or heat available to the tenant could lead to resource exhaustion | |
| 18:09:32 | mriedem | savvas: there is the reserved_host_disk_mb config option | |
| 18:09:36 | prometheanfire | mriedem: hi | |
| 18:09:48 | prometheanfire | http://logs.openstack.org/76/466476/9/check/gate-cross-nova-python27-ubuntu-xenial/89a6a52/testr_results.html.gz | |
| 18:10:01 | mriedem | prometheanfire: was this the same thing as last week? | |
| 18:10:04 | prometheanfire | think the new dogpile.cache makes nova sad | |
| 18:10:05 | prometheanfire | probably | |
| 18:10:09 | mriedem | or 2 weeks ago | |
| 18:10:13 | mriedem | did you open a bug for that? | |
| 18:10:23 | jaypipes | mriedem: no, that was this series: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/resource-provider-traits | |
| 18:10:36 | mriedem | jaypipes: ah ok | |
| 18:10:49 | mriedem | prometheanfire: please report a bug | |
| 18:10:55 | mriedem | i'm doing 4 things at once atm | |
| 18:11:03 | prometheanfire | ya | |
| 18:11:10 | prometheanfire | though I don't see a commit that'd do that | |
| 18:11:17 | jaypipes | mriedem: also, global requiremnts is already at os-traits >= 0.3, so we're cool. | |
| 18:11:26 | jaypipes | mriedem: just need to rebase that fix conflicts | |