| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-05-03 | |||
| 22:04:38 | melwitt | and I was trying to test that both of those queries do the multi-cell thing. but yeah, probably could set this up for a functional test. I'll try it | |
| 22:05:37 | mriedem | with complicated changes like this, i find it's easier to write the functional test to setup the environment like the user would run a use case | |
| 22:05:48 | mriedem | using the actual APIs | |
| 22:05:53 | mriedem | to create the groups and add members to them and such | |
| 22:06:16 | mriedem | otherwise it's too easy to fake things out in the db that aren't accurate | |
| 22:07:17 | melwitt | for whatever reason, I did not expect it would be easy to do a functional test. I agree it would be a lot better to reason about too | |
| 22:07:29 | mriedem | mostly just copy/paste the setup | |
| 22:07:31 | mriedem | pretty easy | |
| 22:08:07 | mriedem | the one thing with multi-cell functional and having different hosts in different cells, you'll need https://review.openstack.org/#/c/558160/ | |
| 22:08:19 | mriedem | otherwise the computes all get created in the default cell1 | |
| 22:08:44 | mriedem | but that's approved now so shouldn't be a problem - you just need to specify the cell you want the compute in when you create it | |
| 22:09:25 | mriedem | i've been told i need to go workout because i've become somewhat of a troll, so ttyl | |
| 22:09:25 | melwitt | I know, I tried to solve that problem with my CellDatabases patch months ago but people weren't okay with it because I did the ServiceWrapper thing | |
| 22:23:03 | openstackgerrit | Jay Pipes proposed openstack/nova master: process groups individually and merge candidates https://review.openstack.org/566180 | |
| 22:52:34 | openstackgerrit | Merged openstack/nova master: Handle @safe_connect returns None side effect in _ensure_resource_provider https://review.openstack.org/566096 | |
| 22:58:45 | openstackgerrit | Merged openstack/nova master: Fix the request context in ServiceFixture https://review.openstack.org/558160 | |
| 23:07:57 | openstackgerrit | Arvind Nadendla proposed openstack/nova-specs master: Handle rebuild of instance with new image https://review.openstack.org/560718 | |
| 23:33:50 | idlemind | http://paste.openstack.org/show/720326/ | |
| 23:34:02 | idlemind | I need those database connections to be updated to .9 not .11 ... what's the best way to do that? | |
| 23:34:25 | idlemind | can i just drop the cells (delete) and they'll get recreated? | |
| 23:34:42 | idlemind | or should i update them | |
| 23:46:08 | openstackgerrit | Oliver Walsh proposed openstack/nova stable/pike: Handle @safe_connect returns None side effect in _ensure_resource_provider https://review.openstack.org/566164 | |
| 23:48:57 | openstackgerrit | Arvind Nadendla proposed openstack/nova-specs master: Handle rebuild of instance with new image https://review.openstack.org/560718 | |
| #openstack-nova - 2018-05-04 | |||
| 00:54:00 | openstackgerrit | Tetsuro Nakamura proposed openstack/nova master: Add tests for alloc_cands with member_of https://review.openstack.org/561399 | |
| 00:54:01 | openstackgerrit | Tetsuro Nakamura proposed openstack/nova master: Fix member_of with sharing providers https://review.openstack.org/561400 | |
| 00:54:02 | openstackgerrit | Tetsuro Nakamura proposed openstack/nova master: Expand member_of functional test cases https://review.openstack.org/566011 | |
| 01:05:26 | mrjazzercise | idlemind: you've got 2 cell1s, so probably drop the one with the wrong URL | |
| 01:05:36 | mrjazzercise | and update the cell0 one using nova-manage cell_v2 update_cell | |
| 01:06:05 | mrjazzercise | some services cache the cells so you'll have to restart some services, check the man page on update_cell | |
| 01:06:21 | mrjazzercise | nova-api, nova-conductor and nova-scheduler i think | |
| 02:09:08 | idlemind | mrjazzercise thx | |
| 04:31:51 | openstackgerrit | jichenjc proposed openstack/nova master: WIP:[doc]Move configuration to admin subfolder https://review.openstack.org/566212 | |
| 05:43:56 | openstackgerrit | jichenjc proposed openstack/nova master: [doc]Move configuration to admin subfolder https://review.openstack.org/566212 | |
| 05:45:35 | nsingh | any command or way to confirm which services running on compute nodes??? | |
| 06:48:25 | openstackgerrit | zhangyangyang proposed openstack/nova master: Remove the function get_back_port() https://review.openstack.org/566219 | |
| 07:37:39 | openstackgerrit | Kashyap Chamarthy proposed openstack/nova stable/ocata: libvirt: Make `cpu_model_extra_flags` case-insensitive for real https://review.openstack.org/565672 | |
| 07:37:39 | bauzas | good morning Nova | |
| 07:37:47 | bauzas | let me put a Friday swag | |
| 08:17:17 | openstackgerrit | Zhenyu Zheng proposed openstack/nova master: WIP new migration threads control https://review.openstack.org/563505 | |
| 08:24:44 | bauwser | andreykurilin: remind me, if I'm using novaclient python bindings for calling Nova, if I'm not providing a specific microversion request, then I get v2.1, right? | |
| 08:25:04 | bauwser | contrary to when using the nova CLI, when we ask for nova.latest microversion, right? | |
| 08:25:30 | bauwser | gibi: if you remind as well ^ | |
| 08:29:11 | bauwser | I mean, when I do a Client('2'), I should only get v2.1 | |
| 08:29:30 | bauwser | actually, I should get /v2 which maps to /v2.1 to be precise | |
| 08:31:14 | bauwser | yeah, confirmed https://github.com/openstack/python-novaclient/blob/master/novaclient/api_versions.py#L233-L234 | |
| 08:31:35 | bauwser | do we have any novaclient specialists here ? | |
| 08:31:42 | bauwser | just to confirm | |
| 08:46:06 | openstackgerrit | Nguyen Hai proposed openstack/nova-specs master: Follow the new PTI for document build https://review.openstack.org/551802 | |
| 08:49:32 | giblet | bauwser: I don't know | |
| 08:49:53 | bauwser | no worries, I think I have all that I want | |
| 08:49:58 | giblet | OK | |
| 08:50:06 | bauwser | we discover the versions with the shell | |
| 08:50:16 | bauwser | but we don't with the python bindings directly | |
| 09:51:44 | rabel_ | hi there. I just saw that add-floating-ip action is deprecated in compute api. but how is a floating ip associated to an instance then? | |
| 09:55:48 | rabel_ | found it. network api https://developer.openstack.org/api-ref/network/v2/#floating-ips-floatingips | |
| 10:48:42 | openstackgerrit | Stephen Finucane proposed openstack/nova-specs master: Add 'numa-aware-vswitches' spec https://review.openstack.org/541290 | |
| 10:49:20 | finucannot | jaypipes, giblet: OK, I think that spec is good to go now. I've clarified a lot of the physnet/provider net stuff and fixed the diagrams https://review.openstack.org/541290 | |
| 10:55:42 | giblet | finucannot: looking | |
| 11:01:59 | openstackgerrit | Surya Seetharaman proposed openstack/nova stable/queens: Make association_refresh configurable https://review.openstack.org/566288 | |
| 11:08:37 | giblet | finucannot: your spec looks good to me | |
| 11:50:03 | openstackgerrit | Balazs Gibizer proposed openstack/nova-specs master: Placement: any traits in allocation_candidate query https://review.openstack.org/565730 | |
| 11:50:31 | openstackgerrit | Balazs Gibizer proposed openstack/nova-specs master: Placement: support mixing required traits with any traits https://review.openstack.org/565741 | |
| 12:02:40 | openstackgerrit | Balazs Gibizer proposed openstack/nova-specs master: Placement: support mixing required traits with any traits https://review.openstack.org/565741 | |
| 12:06:22 | jmccarthy | Hmm I still have this issue where after a cold migration, a disk.info file shows up in instance dir and is left on source host | |
| 12:06:43 | jmccarthy | I'm using kolla stable/queens - does this log seem right ? | |
| 12:06:45 | jmccarthy | http://paste.openstack.org/show/720358/ | |
| 12:07:13 | jmccarthy | It's when the resize/migration is confirmed that it shows up | |
| 12:09:40 | jmccarthy | This part looks good CMD "rm -rf /var/lib/nova/instances/371e669b-0f15-49f2-9a84-bd1e89f34294_resize" returned: 0 | |
| 12:10:00 | jmccarthy | But then a lock is acquired on disk.info *after that ? and it's left there .. | |
| 12:21:22 | jmccarthy | After migrating an instance, is /var/lib/nova/instances/371e669b-0f15-49f2-9a84-bd1e89f34294/disk.info supposed to written out on the source host ? | |
| 12:21:46 | jmccarthy | s/After/After cold-/ | |
| 12:31:19 | openstackgerrit | Merged openstack/nova master: libvirt: Drop BAD_LIBVIRT_CPU_POLICY_VERSIONS https://review.openstack.org/564012 | |
| 12:31:25 | openstackgerrit | Merged openstack/nova master: libvirt: Drop MIN_QEMU_POSTCOPY_VERSION https://review.openstack.org/565724 | |
| 12:31:33 | openstackgerrit | Merged openstack/nova master: libvirt: Drop MIN_LIBVIRT_REALTIME_VERSION https://review.openstack.org/565707 | |
| 12:37:29 | finucannot | giblet: One thought I had on numa-aware-vswitches: how do we deal with changes in the networks attached to the guest when migrating? I think you touched on that here https://review.openstack.org/#/c/541290/8/specs/rocky/approved/numa-aware-vswitches.rst@243 | |
| 12:38:25 | giblet | finucannot: yes. even if the network itself is not changing the NUMA affinity of the devices providing access to the given network can be different on different hosts | |
| 12:39:01 | giblet | finucannot: and the actual physnet can change if we have multiprovider networks with mutliple segments having different physnets | |
| 12:39:23 | giblet | finucannot: but the later does not supported today by nova anyhow | |
| 12:39:28 | finucannot | OK, I don't think that's actually an issue. In that case, we'd be regenerating the guest NUMA topology for the new host and that would use the new host's NUMA-network mapping | |
| 12:39:41 | finucannot | Also, I think we decided multi-segment is out-of-scope | |
| 12:39:59 | giblet | finucannot: multi-segment is out of scope, I agree | |
| 12:40:23 | finucannot | I'm more concerned about the actual networks attached. We've said that a user has to allocate networks at instance creation time so we can do NUMA affinity | |
| 12:40:51 | finucannot | However, you can attach/detach networks to/from a running instance, right? | |
| 12:40:52 | giblet | finucannot: could you be bit more specific how the network changes in your scenario | |
| 12:41:00 | giblet | finucannot: ahh, yes | |
| 12:41:28 | finucannot | So I boot an instance attached to network 'foo' and then, once it's running, detach from 'foo' and attach to 'bar' | |
| 12:41:37 | giblet | finucannot: when you attach a new port / network that might affect the necessary affinity | |
| 12:42:09 | finucannot | Yeah, exactly. We can't do anything about that while the instance is on the same host, but what about if we migrate/rebuild? | |
| 12:42:47 | giblet | finucannot: you can actually check if the port being attached creates a contradiction with the existing affinity of the instance | |
| 12:43:01 | giblet | finucannot: and you might reject the attach | |
| 12:43:45 | giblet | finucannot: but I agree that when you migrate you have to take every port / network into account | |
| 12:43:58 | giblet | finucannot: including those that was attached after the boot | |
| 12:44:40 | finucannot | Yeah, we could do that. I guess that could/should be a configurable policy option down the line | |
| 12:45:35 | finucannot | But yeah, I'm thinking I should regenerate the NetworkRequestList object attached to the instance/request spec when migrating to reflect the network topology pre-migration | |
| 12:45:42 | finucannot | That might even happen already. I should check | |
| 12:46:24 | giblet | finucannot: I think regenerating the information from Neutron is the safe solution | |
| 12:47:15 | giblet | finucannot: I would even go that far that don't persist the NetworkRequestList but simply regenerate when it is needed | |
| 12:52:15 | finucannot | You need to though so that you can use it during claiming. Without that we have no way to figure out what's necessary https://review.openstack.org/#/c/541290/8/specs/rocky/approved/numa-aware-vswitches.rst@243 | |
| 12:52:21 | finucannot | whoops | |
| 12:52:28 | finucannot | https://review.openstack.org/#/c/564449/1/nova/compute/claims.py | |