| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-05-03 | |||
| 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 | bauzas | good morning Nova | |
| 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: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 | |
| 12:53:34 | finucannot | It also needs to be stored in the RequestSpec object so that we don't need to query neutron from the filters (which we can't do because we don't have correct context) | |
| 12:55:14 | giblet | finucannot: does the RequestSpec loaded from the db in the scheduler or passed via rpc? | |
| 12:55:31 | finucannot | The former, to the best of my knowledge | |
| 12:56:00 | giblet | finucannot: then I agree that you have to store the NetworkREquestList to the db along with the RequestSpec | |
| 12:56:43 | finucannot | Yeah, I mapped the whole thing here http://paste.openstack.org/show/720365/ | |
| 12:59:58 | giblet | finucannot: I think the RequestSpec is passed to the scheduler via rpc https://github.com/openstack/nova/blob/5d97937c3c56a3e240a3350a7a9f0e3dcb954c52/nova/scheduler/rpcapi.py#L132 | |
| 13:00:34 | giblet | the spec_obj there is a RequestSpec obj | |
| 13:03:33 | giblet | finucannot: also the build_and_run_instance leading to the claim gets the instance object via rpc | |
| 13:04:46 | finucannot | Yup, so if I wanted to, for example, pass an additional 'network_requests' parameter to 'claim()', I guess I'd have to bump the RPC version | |
| 13:05:01 | finucannot | I'm pretty sure I looked at that though and it wasn't possible. Lemme look again | |
| 13:06:29 | giblet | finucannot: you can still add the network_requests as a field to the Instance ovo and to the RequestSpec ovo, but you not necessary to persist the content of that fields to the db, as the user of that field always get the object via rpc and the sender can regenerate the content of the network_request | |
| 13:07:44 | giblet | so in case of boot, the conductor generates the content of the network_request field and pass it down via the ReqestSpec of the Instance object | |
| 13:07:52 | giblet | similarly in case of a VM move operation | |
| 13:09:49 | finucannot | Yeah, that shouldn't be an issue for RequestSpec as I don't think those are persisted. What about Instance though. Can you mark a field in a persistent object as non-persistent? | |
| 13:09:49 | giblet | persistence is itching my mind because this data is already persisted in neutron so as soon as nova also persist it we will have two possible divergent copies | |
| 13:11:10 | giblet | finucannot: there is a request_specs table in the api db so your technical problem how to not persist a field is valid for both object | |
| 13:13:17 | giblet | finucannot: we should ask dansmith about this persistency issue but I have an idea | |
| 13:13:24 | giblet | finucannot: make the new field lazy_loaded | |