| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-06-07 | |||
| 13:13:15 | mriedem | *don't need | |
| 13:13:51 | stvnoyes | it should be ok for this case, the old attach ids are not relevant after the migration | |
| 13:19:15 | dansmith | alex_xu: if it's entirely compatible with what we have, then we can | |
| 13:19:28 | dansmith | alex_xu: not sure how I feel about that status enum change, but I'll take a look | |
| 13:20:27 | alex_xu | dansmith: thanks | |
| 13:20:33 | mriedem | alex_xu: dansmith: at some point i should go over those again too, because in an earlier revision on that series i reviewed i was worried about the migration status enums being biased toward being able to abort a cold migration | |
| 13:20:47 | mriedem | it all seemed very tightly coupled to the api | |
| 13:21:27 | mriedem | https://review.openstack.org/#/c/430608/18/nova/objects/fields.py@1055 | |
| 13:22:38 | openstackgerrit | Merged openstack/nova master: Remove cells topic configuration option https://review.openstack.org/463218 | |
| 13:23:05 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Add PCIWeigher https://review.openstack.org/379524 | |
| 13:23:08 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Prefer non-PCI host nodes for non-PCI instances https://review.openstack.org/379625 | |
| 13:23:18 | mriedem | given we have 20 different migration statuses and 4 different types of migration, getting this all right is a mess | |
| 13:23:38 | alex_xu | mriedem: I remember we said the reverting and confirming didn't have actualy data copy, and it can't be abort, so we didn't count those status as in-progress | |
| 13:23:40 | mriedem | plus when it's baked into the api it's going to be even more of a mess if we screw it up, because contracts | |
| 13:24:04 | mriedem | alex_xu: i think what's considered an "in-progress" migration shouldn't be coupled to what you can or can't abort | |
| 13:24:11 | mriedem | that's a higher-level whitelist in the API imo | |
| 13:24:27 | mriedem | so there might be 10 different in-progress states for a resize, but you can only abort 5 of those | |
| 13:24:30 | alex_xu | mriedem: oh, i probably get your point | |
| 13:24:47 | mriedem | the object layer should report the real in-progress states, the api should control which you can operate on | |
| 13:25:13 | openstackgerrit | Matthew Edmonds proposed openstack/nova master: [WIP] Deactivate powervm compute until ready https://review.openstack.org/471773 | |
| 13:25:58 | alex_xu | mriedem: but we list in-progress migrations from the object layer, it still couple together? | |
| 13:27:36 | alex_xu | mriedem: oh, you mean in-progress and abort-able is different set | |
| 13:32:52 | mriedem | correct | |
| 13:33:08 | mriedem | i would prefer to not couple those | |
| 13:37:01 | alex_xu | mriedem: yea, agree with that, and I feel this patch fix a bug also https://review.openstack.org/#/c/459483/11/nova/compute/api.py@4030 | |
| 13:44:14 | mriedem | alex_xu: ok i went through https://review.openstack.org/#/c/468619/ | |
| 13:44:26 | mriedem | just some small things to fix | |
| 13:47:05 | mriedem | alex_xu: also replied in https://review.openstack.org/#/c/459483/11/nova/compute/api.py@4030 - it's confusing but i don't think it's a bug fix | |
| 13:59:30 | alex_xu | mriedem: replied | |
| 14:00:57 | alex_xu | sdague: for https://review.openstack.org/#/c/468619/, I want to hear from you whether we should fix it for legacy v2 API. I didn't remember we discuss what we should do for legacy v2, just want to ensure we consider that case. | |
| 14:01:37 | sdague | alex_xu: ok, I'm not going to have enough bw to comment usefully for a couple of days on that | |
| 14:02:24 | sdague | alex_xu: while you are still active though, https://review.openstack.org/#/c/468356/ is the last global_request_id call from nova | |
| 14:03:16 | alex_xu | sdague: ok, no problem, no rush for that fix, we have enough time | |
| 14:04:12 | alex_xu | sdague: will try review that after few mins | |
| 14:09:30 | bauzas | dansmith: melwitt: quick bugfix needing a +W https://review.openstack.org/#/c/471487/3 | |
| 14:09:39 | bauzas | I'll backport it to stables | |
| 14:09:56 | kashyap | sdague: I haven't run DevStack in a little while, do you have a minimal DevStack (Nova, Keystone, Glance and Neutron) config handy somewhere? | |
| 14:10:21 | kashyap | sdague: I'm asking as certain things have changed - like using systemd as opposed to `screen`, etc. | |
| 14:11:14 | sdague | kashyap: that should be the out of the box | |
| 14:11:33 | sdague | specify the 4 passwords, and you are fine (it will prompt you for them otherwise) | |
| 14:11:43 | bauzas | kashyap: unless you defined USE_SCREEN=yes, the config is not changed | |
| 14:12:06 | bauzas | kashyap: so you can take even a very old one | |
| 14:12:19 | kashyap | sdague: Noted. But I care about certain things like these - https://kashyapc.fedorapeople.org/virt/openstack/Minimal-DevStack-local.conf | |
| 14:12:38 | kashyap | And disable services (e.g. n-ec2) that I don't want | |
| 14:12:46 | kashyap | bauzas: Ah, noted. | |
| 14:12:48 | sdague | kashyap: n-ec2 isn't a thing any more | |
| 14:12:55 | bauzas | kashyap: and n-net too | |
| 14:13:03 | kashyap | bauzas: Yep, aware of the n-net; | |
| 14:13:06 | sdague | kashyap: honestly, I would delete all that | |
| 14:13:11 | bauzas | but yours is Neutron | |
| 14:13:11 | sdague | my minimal config is | |
| 14:13:17 | sdague | [[local|localrc]] | |
| 14:13:17 | sdague | ADMIN_PASSWORD=pass | |
| 14:13:17 | sdague | DATABASE_PASSWORD=pass | |
| 14:13:17 | sdague | RABBIT_PASSWORD=pass | |
| 14:13:19 | sdague | SERVICE_PASSWORD=pass | |
| 14:13:38 | sdague | all those networking things should not be required for working neutron anymore | |
| 14:14:10 | kashyap | sdague: Can you run this quick command -- `ps_mem` -- from inside the DevStack VM for me, and post the output somewhere? | |
| 14:14:22 | dansmith | bauzas: done | |
| 14:14:30 | sdague | kashyap: I'm not on a vm, I've got a real machine | |
| 14:14:37 | sdague | and ps_mem doesn't seem to be a command here | |
| 14:14:40 | bauzas | dansmith: cools | |
| 14:14:43 | kashyap | sdague: Sure, real machine does it, too | |
| 14:14:47 | kashyap | Wait let me get a URL for it | |
| 14:14:55 | kashyap | sdague: http://www.pixelbeat.org/scripts/ps_mem.py | |
| 14:15:06 | dansmith | bauzas: that one line of code has had like five bug fixes | |
| 14:15:12 | dansmith | bauzas: it's hall of fame stuff | |
| 14:15:22 | kashyap | sdague: The output would look something like - https://kashyapc.fedorapeople.org/virt/openstack/DevStack_Memory_Profile_29NOV2016_on_F25.txt | |
| 14:15:29 | bauzas | dansmith: which line ? :) | |
| 14:15:50 | bauzas | on the default_conn() ? heh | |
| 14:15:55 | sdague | http://paste.openstack.org/show/611722/ | |
| 14:16:02 | dansmith | bauzas: just the calculation of the cell0 name I mean | |
| 14:16:09 | bauzas | dansmith: honestly, it's errorprone | |
| 14:16:29 | bauzas | given we need to support all the crazypants that operators can provide as strings | |
| 14:17:05 | bauzas | fun fact is that I verified, and I can actually use UTF-8 encoded creds with our current :) | |
| 14:17:19 | bauzas | if I was just providing the string like this | |
| 14:17:45 | bauzas | 'herv\xc3\xa9' | |
| 14:21:31 | openstackgerrit | Gábor Antal proposed openstack/nova master: Transform instance.live_migration_rollback notification https://review.openstack.org/402124 | |
| 14:21:51 | d3n14l | Can someone tell me why a `openstack server list`repeatedly takes >15s for "just" 200 servers? (On openstack-ansible deployment, configured memcache and no slow request on the galera cluster…) See https://pastebin.com/nMivFhMA | |
| 14:23:55 | openstackgerrit | Gábor Antal proposed openstack/nova master: Transform instance.live_migration_rollback notification https://review.openstack.org/402124 | |
| 14:23:59 | kashyap | sdague: Thank you | |
| 14:24:45 | openstackgerrit | Merged openstack/python-novaclient master: Prevent 2.32 release note from showing up in 9.0.0 release notes https://review.openstack.org/471383 | |
| 14:24:49 | kashyap | sdague: Is this a "pure DevStack" host? | |
| 14:25:14 | kashyap | sdague: Because your setup is consuming 4.5 GB of memory; if you saw mine above, it was operating with 2.5GB | |
| 14:25:25 | sdague | kashyap: it is | |
| 14:25:34 | sdague | it's also been running for some amount of time | |
| 14:26:15 | kashyap | Noted; thanks | |
| 14:26:39 | sdague | while it never had a tempest run, I was doing some testing with guests booting so it's had about 30 - 40 cirros guests boot / delete | |
| 14:31:17 | kashyap | Ah | |
| 14:31:26 | kashyap | sdague: Any improvement with this: `free -m && sync && echo 3 > /proc/sys/vm/drop_caches && free -m` | |
| 14:31:32 | kashyap | As root | |
| 14:34:07 | sdague | kashyap: well that dumped my buffer cache | |
| 14:34:15 | sdague | but it doesn't change the ps_mem output | |
| 14:34:36 | kashyap | sdague: Whoops, thought you've read the line. That's why I didn't explain it, sorry :-( | |
| 14:34:49 | kashyap | But thank you for testing | |
| 14:35:05 | sdague | kashyap: what did you think I read? | |
| 14:35:25 | sdague | kashyap: what was your intent with the free calls? | |
| 14:35:25 | kashyap | The command sequence in quotes | |
| 14:35:48 | sdague | kashyap: sure, I guess I'm just not sure what you were asking for as "improvement" | |
| 14:35:51 | kashyap | Just to see if dropping 'needless' things in the caches will show what's the bare-minimal memory occupation | |