Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-02-27
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
23:38:13 openstackgerrit Dan Smith proposed openstack/nova master: Add cell field to Destination object https://review.openstack.org/438024
23:38:14 openstackgerrit Dan Smith proposed openstack/nova master: WIP: Make conductor ask scheduler to limit migrates to same cell https://review.openstack.org/438025
23:40:47 openstackgerrit Eric Fried proposed openstack/nova master: PowerVM Driver: spawn/destroy #4: full flavor https://review.openstack.org/391288
23:53:47 openstackgerrit John Griffith proposed openstack/nova master: Add attachment_uuid to BDM table https://review.openstack.org/438744
23:56:42 mikal tonyb: mriedem went away so I can't tell him why we reverted that thing
23:56:45 mikal So that went well
23:57:17 tonyb mikal: :( Tell me and he can read the logs
23:57:47 mikal tonyb: the ploop stuff exposes a config drive which uses an ext4 filesystem. This works for the parallels guys because they assume that all their "instances" are linux for obvious reasons.
23:58:16 mikal tonyb: however the ploop support is added in a way that say, libvirt, could use a ploop config drive as well
23:58:32 mikal tonyb: which means every guest OS in the world now needs to support ext4 because of a possible deployer choice
23:58:39 mikal tonyb: which isn't great for something like a windows guest
23:58:46 dansmith yeah, that sucks
23:58:57 dansmith I wish we had that context whilst discussing it
23:59:13 mikal tonyb: we had a long argument at the time about how we'd deliberately picked fat and iso9660 because they were universally supported by our guest OSes
23:59:23 mikal tonyb: and in fact every conceivable OS
23:59:42 mikal tonyb: until we discovered that parallel in fact supports neither of those, as they have no way to mount a block device
23:59:49 dansmith is there some reason they can't just use fat for that as well?
23:59:50 dansmith ah
#openstack-nova - 2017-02-28
00:00:00 dansmith now, he made it sound like they _do_ have a block device even in the containery thing
00:00:07 mikal We talked through a user space fat implementation they could use instead
00:00:20 mikal And they shook their fists at us for being big meanies
00:00:39 mikal I have no comment on if the block thing is still true

Earlier   Later