| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-02-27 | |||
| 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: Change MQ targeting to honor only what is in the context https://review.openstack.org/438023 | |
| 23:25:02 | openstackgerrit | Dan Smith proposed openstack/nova master: Target cell in conductor cold migrate https://review.openstack.org/438022 | |
| 23:25:03 | openstackgerrit | Dan Smith proposed openstack/nova master: Add cell field to Destination object https://review.openstack.org/438024 | |
| 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: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: Add cell field to Destination object https://review.openstack.org/438024 | |
| 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: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 | |
| 00:00:44 | mikal | Simply don't know | |
| 00:01:15 | dansmith | mikal: can you make sure that all gets reflected in the current patches? I'll circle back and admit I didn't have that context while we were discussing it and I was not coming up with any reasons to block it | |
| 00:01:25 | dansmith | (which is why we wanted to re-get your context post-ptg) | |
| 00:01:51 | mikal | Sure. Its not going to happen today though. I'll try and get it done by the end of the week. | |
| 00:02:05 | mikal | I'm currently trying to remember why a directory on the host OS was better than a ext4 filesystem | |
| 00:02:11 | mikal | And its not coming to me instantly | |
| 00:02:41 | dansmith | well, it is the same behavior for lxc and parallels, and doesn't require needing to know what filesystem is there | |
| 00:03:01 | mikal | I do recall someone else wanting directories, it might have been LXC | |
| 00:03:05 | mikal | I'm a bit fuzzy on the details | |