Earlier  
Posted Nick Remark
#openstack-nova - 2017-02-27
18:18:55 sfinucan tl;dr: IMO, cliff is broken by design and no one should be using it. In addition, click offers enough cool things to justify its inclusion in g-r
18:20:00 sfinucan I'd be happy to try talk the openstackclient team around, but without "code on the table" I doubt I'd get far :)
18:20:35 openstackgerrit Maciej Szankin proposed openstack/nova master: conf: remove *_topic config opts https://review.openstack.org/433924
18:21:26 sdague sfinucan: well, feel free to have the conversation with the openstack client team, but definitely personally -1 on replacing one different CLI system with another one, instead of standardizing into what everyone else in the community is using
18:21:57 dansmith me too
18:22:35 openstackgerrit John L. Villalovos proposed openstack/nova master: Use flake8-import-order https://review.openstack.org/435575
18:24:01 sfinucan sdague: I do think they're standardizing on a bad choice but that's understandable
18:25:25 sdague sfinucan: well, there is a ton of experience in the community, cliff was adopted into openstack as an openstack project, so am very much not interested in running off in a different direction
18:27:20 sfinucan sdague: Yup, standardizing on things is good. It's just that I think cliff is a poor choice to standardize on
18:29:00 sdague sfinucan: ok, well get in a time machine and go back to 2013 and have that argument :)
18:29:20 sfinucan :)
18:51:47 openstackgerrit Stephen Finucane proposed openstack/nova-specs master: Reserve NUMA nodes with PCI devices attached https://review.openstack.org/364468
18:55:19 openstackgerrit Chris Friesen proposed openstack/python-novaclient master: Add support for showing flavor details (v2.43) https://review.openstack.org/435141
19:02:14 mriedem cfriesen: i added the co-authored-by on your newton reno
19:02:21 mriedem +2 now
19:08:25 cfriesen mriedem: oops, missed that. thanks for the tweak
19:33:01 openstackgerrit Sujitha proposed openstack/nova master: Remove mox from nova.tests.unit.virt.xenapi.test_vmops.GetConsoleOutputTestCase https://review.openstack.org/438678
19:35:04 openstackgerrit Sujitha proposed openstack/nova master: Remove mox from nova.tests.unit.virt.xenapi.test_vmops[1] https://review.openstack.org/438678
20:21:15 mriedem sdague: did you ever find a patch to remove LocalFS?
20:21:26 mriedem i couldn't find one of yours like that
20:21:39 sdague I might have abanoned it, let me go look
20:22:26 sdague https://review.openstack.org/#/c/324720/3 - just restored and recheck
20:46:25 mriedem melwitt: on https://review.openstack.org/#/c/431749/ - was there anything you wanted to add to that given the discussion at the PTG about adding project/user IDs to the placement API for handling quota when a cell is down?
21:04:31 mriedem sdague: just checking, but did you agree to take a stab at a spec for storing limits in keystone?
21:05:11 sdague mriedem: yeh, I need to go look at the keystone spec
21:05:25 mriedem ok, just updating some notes
21:05:25 mriedem thanks
21:07:04 cfriesen what's the current view on cleaning up stale data in the nova db? is there a way to clean up all the tables, or just some? And is anyone working on improving it?
21:07:31 mriedem cfriesen: there is the archive command
21:07:35 mriedem but that just moves to shadow tables
21:07:46 mriedem there was a spec/effort at one point for adding a purge instances command
21:07:53 mriedem but withered on the vine, needs an owner
21:09:02 cfriesen mriedem: this one? https://blueprints.launchpad.net/nova/+spec/purge-deleted-instances-cmd
21:09:48 mriedem yeah
21:09:58 mriedem spec would have to be re-proposed for pike
21:27:43 mriedem raj_singh: sdague: efried: i'm seeing several rechecks on https://review.openstack.org/#/c/412634/ but the py35 dsvm job failures look legit
21:27:49 mriedem http://logs.openstack.org/34/412634/25/check/gate-tempest-dsvm-py35-ubuntu-xenial/c7c593e/logs/screen-n-api.txt.gz?level=TRACE
21:29:08 openstackgerrit Sean Dague proposed openstack/nova master: Adopts keystoneauth with glance client. https://review.openstack.org/412634
21:29:29 sdague mriedem: ok, let me rebase to master to see if it was keeping a very odd old parent on some things
21:30:56 mriedem ok, the failure isn't clear to me otherwise
21:32:26 mriedem http://logs.openstack.org/34/412634/25/check/gate-tempest-dsvm-py35-ubuntu-xenial/c7c593e/logs/screen-g-api.txt.gz#_2017-02-24_03_57_52_828 is the g-api response i think
21:32:27 sdague mriedem: yeh, the patch being from Feb 13 means that I expect there remained broken things on the python 35 side in nova
21:32:32 sdague that only fixed much later
21:32:57 sdague mriedem: ok, well lets see what a clean rebase gives us
21:33:19 sdague I'd rather not chase until we know we're working off a base that we know works in python3.5
21:33:36 mriedem sure
21:33:44 mriedem also, we have a way to enable glanceclient debug if we need to debug this
21:33:53 mriedem since it's not tracing the requests/responses
21:34:13 mriedem https://github.com/openstack/nova/blob/master/nova/conf/glance.py#L87
21:35:00 mriedem dansmith: i can drop this now right? https://review.openstack.org/#/c/420976/
21:35:03 mriedem you're using something else
21:35:11 dansmith mriedem: yeah
21:35:32 raj_singh sdague: thx. If this rebase does not fix then I will debug it tomorrow.
21:35:38 mriedem dansmith: and this? https://review.openstack.org/#/c/421399/
21:36:19 dansmith mriedem: no, I'll have to have that when I make this spawn conductors on the subnode
21:36:35 mriedem ok
21:36:47 sdague raj_singh: sounds great
21:57:43 mriedem dansmith: L22 in https://etherpad.openstack.org/p/nova-ptg-pike-cells - can you link that in there?
21:58:02 dansmith jess
21:58:07 mriedem i thought that was https://review.openstack.org/#/c/436094/
21:58:11 mriedem but wasn't sure
21:58:30 dansmith yup
22:14:36 mriedem the super-conductor / fleet stuff is really not discussed at all in https://etherpad.openstack.org/p/nova-ptg-pike-cells
22:14:56 mriedem so i'm at a loss for notes besides wanting to move all conductors in the multinode job to the subnode
22:15:14 mriedem i don't have the whiteboard picture either
22:15:20 mriedem did that get posted anywhere?
22:15:53 dansmith mriedem: the fleeting notion (hah) came from an ad-hoc discussion on monday
22:16:13 cburgess I'm vaguely recalling at one point that ironic wanted a way to lock an image to flavor (or vice versa), did anything for that ever get implementing in nova?
22:16:41 mriedem cburgess: doesn't ring a bell
22:17:37 mriedem dansmith: can you give me the high level idea? i know we also talked about some various job configs where this wouldn't work, or something about how we couldn't run it with the live migration tests because they'd try to jump cells
22:17:56 cburgess mriedem Well my brain and memory isn't what it used to be so I could be confusing different things. I did a quick search in nova and couldn't find anything, was just curious. I have a client asking about doing something similiar right now and before I go tell them why their idea is bad I wanted to be sure I could just tell them how to do it (even if it is bad).
22:18:21 dansmith mriedem: I think the solution to the test thing is to make (or make sure) the live migration job doesn't fleet conductors and does have cold migration tests enabled
22:18:44 dansmith mriedem: but basically, we have one conductor per cell (two cells, thus two cell conductors in a normal multinode job)
22:19:02 dansmith mriedem: and then another one which sits at the top level for build and migrate
22:19:15 dansmith mriedem: all of those will load up on the subnode in d-g
22:19:19 mriedem top level is the super conductor
22:19:23 dansmith yeah
22:19:51 mriedem and the super conductor points to the nova_api db?
22:20:13 mriedem or no db?
22:20:15 mriedem just cell0
22:20:23 dansmith mriedem: the nova.conf for the superconductor has api_db credentials, and has its main set to cell0 just to defeat any cheating
22:21:32 mriedem since we don't support migrating across cells, we had the issue of how to resolve that (i remember talking about that on the way to big ted's buffalo banquet on thurs night) - which was support migration across cells, or hack into the scheduler that you can only move within the same cell for now
22:21:40 mriedem is that still TBD?
22:23:25 dansmith mriedem: I have the scheduler modified to restrict to single-cell migrations
22:23:48 dansmith mriedem: so we need to just make sure the live migration job has one cell for both nodes and the cold migration tests enabled
22:23:54 dansmith mriedem: https://review.openstack.org/#/c/438025/
22:24:02 dansmith working on cleaning this stack right now, by the way
22:25:43 mriedem is that your way of telling me to leave you alone? :P
22:25:53 mriedem i dumped some notes in the etherpad
22:25:59 dansmith no, just explaining all the fails on that WIP patch :)
22:26:00 mriedem i think i've got enough for a recap email now
22:26:03 mriedem ok
23:04:19 openstackgerrit Eric Fried proposed openstack/nova master: PowerVM Driver: spawn/destroy #3: TaskFlow https://review.openstack.org/438729
23:25:02 openstackgerrit Dan Smith proposed openstack/nova master: Target cell in conductor cold migrate https://review.openstack.org/438022
23:25:02 openstackgerrit Dan Smith proposed openstack/nova master: Change MQ targeting to honor only what is in the context https://review.openstack.org/438023
23:25:03 openstackgerrit Dan Smith proposed openstack/nova master: Make compute/api instance get set target cell on context https://review.openstack.org/437355
23:25:03 openstackgerrit Dan Smith proposed openstack/nova master: Add cell field to Destination object https://review.openstack.org/438024
23:25:04 openstackgerrit Dan Smith proposed openstack/nova master: WIP: Make conductor ask scheduler to limit migrates to same cell https://review.openstack.org/438025
23:38:12 openstackgerrit Dan Smith proposed openstack/nova master: Target cell in conductor cold migrate https://review.openstack.org/438022
23:38:13 openstackgerrit Dan Smith proposed openstack/nova master: Change MQ targeting to honor only what is in the context https://review.openstack.org/438023

Earlier   Later