Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-05-03
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 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?

Earlier   Later