Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-04-24
08:41:19 johnthetubaguy Nova then (eventually) will send to neutron the os-vif response to say what the host supports
08:41:35 johnthetubaguy neutron then picks from that what it thinks its best from its side of things
08:42:07 johnthetubaguy the port binding info is then returned as a serialized os-vif object, that needs to tell os-vif exactly what needs to get setup
08:42:19 johnthetubaguy or something like that (wibble inspect the instance and the host, etc)
08:42:36 johnthetubaguy its not clear how this all fits into that pattern, for me at least
08:43:46 johnthetubaguy sfinucan: is that the kinda stuff you were thinking, or is that orthogonal?
08:47:50 moshele johnthetubaguy: this is orthogonal because we to doument the plug/unplug of each vif plugin
08:50:24 moshele johnthetubaguy: basiclly doumenting parts like https://github.com/openstack/os-vif/blob/master/vif_plug_ovs/ovs.py#L154-L174 as it become to match complex. sfinucan are we on the same page?
08:53:16 johnthetubaguy moshele: ah, understood, that certainly looks out of hand
08:54:08 johnthetubaguy moshele: I was kinda expecting each of those vif objects to do the thing they needed, rather than having massive If statement
08:57:10 moshele johnthetubaguy: the ovs-plugin just say it used with the OVS mechanism driver, but there are several ways to achieve binding (plain ovs/ hybrid with lb/DPDK/windows) each one is an if statement
08:58:00 sfinucan moshele: Yeah, exactly
08:58:03 sfinucan As a start
08:58:12 johnthetubaguy moshele: yeah thats certainly the current state, that seems bad, you could use the object structure to remove the all the ifs I would have thought
08:58:37 johnthetubaguy I guess I was expecting those to all get advertised as separate things in some ways, just sharing a common set of utils
08:58:38 sfinucan johnthetubaguy: There's definitely good reason to go the way you're suggesting but that'd be a different series
08:58:45 johnthetubaguy sfinucan: oh, totally
08:58:52 johnthetubaguy just thinking out loud really
08:58:57 openstackgerrit Zhenyu Zheng proposed openstack/nova master: Rework descriptions in os-hypervisors https://review.openstack.org/452030
08:59:58 sfinucan moshele: So if you wanted to add a document with description of that particular VIF driver, I'd be happy enough for now
09:00:47 sfinucan We could collectively expand it out to all the other VIF types after the fact
09:01:34 moshele sfinucan: sure I will start something and let see where we go with it
09:01:41 sfinucan (y) Cheers :)
09:13:39 abhi89 johnthetubaguy: Hi
09:14:45 johnthetubaguy abhi89: hi
09:16:33 abhi89 i have thought of a solution to https://review.openstack.org/#/c/455118/3 & commented after your comments.. can you please take a look & let me know about whether that would be the right way to proceed
09:19:22 openstackgerrit Lee Yarwood proposed openstack/nova master: libvirt: Always disconnect_volume after rebase failures https://review.openstack.org/458807
09:19:29 johnthetubaguy abhi89: can we get a stack trace out the system that is seeing this error
09:19:46 johnthetubaguy abhi89: your current patch still doesn't look like it would fix the problem, based on what is described
09:20:51 abhi89 johnthetubaguy: stacktrace will have VolumeLimitExceeded() exception, i will attach the stacktrace also
09:21:29 abhi89 johnthetubaguy: i haven't made those changes to my current patch. i have just proposed a solution that i thought of
09:21:33 johnthetubaguy abhi89: right, thats what I expected, the code you have added is not reachable
09:21:46 johnthetubaguy abhi89: ah... sorry, let me read the comments not the code
09:22:12 abhi89 yes.. please go through my comment of proposed solution once
09:23:00 johnthetubaguy abhi89: we do need to translate the exception, its a common patter we have for all cinder errors. What I would do is just add additional information into the translated exception
09:24:37 sfinucan johnthetubaguy: Could you stick these on your review queue? https://review.openstack.org/#/q/status:open+topic:bp/move-nova-cmds-to-cliff
09:24:47 johnthetubaguy abhi89: I would recommend you instead look at this line of code: https://github.com/openstack/nova/blob/5a6d4e089dca2515c0f7e083a8b903ac7a166773/nova/volume/cinder.py#L203
09:24:54 sfinucan I'd like to get them merged this cycle so I can push on with that bp next cycle
09:26:36 abhi89 johnthetubaguy: yes. we can even add additional information to the translated exception at https://github.com/openstack/nova/blob/5a6d4e089dca2515c0f7e083a8b903ac7a166773/nova/volume/cinder.py#L203
09:27:11 johnthetubaguy sfinucan: possibly, my queue is getting a bit silly right now, particularly given I don't have a job by the time the summit happens, AFAIK :(
09:27:11 abhi89 johnthetubaguy: i will try this out
09:27:23 johnthetubaguy abhi89: thanks, I think thats probably going to be easiest way to fix it
09:27:42 abhi89 johnthetubaguy: yes, thanks for your suggestion
09:28:05 johnthetubaguy abhi89: no problems, sorry I didn't add that on the first set of comments, I should have.
09:28:55 johnthetubaguy sfinucan: oh, wait, I see, its tiny
09:31:08 sfinucan johnthetubaguy: Yeah they're tidy enough. If you've enough on your plate though then they certainly wait
09:38:27 openstackgerrit jichenjc proposed openstack/nova-specs master: Add os-quota-class-sets-query-update https://review.openstack.org/459185
10:01:57 openstackgerrit Takashi NATSUME proposed openstack/nova master: List/show all server migration types https://review.openstack.org/430608
10:06:48 openstackgerrit jichenjc proposed openstack/nova master: Use plain routes list for limits endpoint instead of stevedore https://review.openstack.org/458805
10:18:15 bhagyashris cdent: Hi,
10:21:54 cdent hi bhagyashris, what's up?
10:31:48 openstackgerrit jichenjc proposed openstack/nova master: Use plain routes list for hosts endpoint instead of stevedore https://review.openstack.org/459231
10:32:35 bhagyashris cdent: Fine. I have one doubt. Actually I have configured the multinode setup and tried to use the nfs shared storage. so How can I used the single resource provider in multinode setup?
10:34:06 cdent bhagyashris: are you saying you want to track the nfs share as a resource provider? If so, that's not yet supported. It's still the case that the compute-node will report the disk to which it has access. Shared resource providers is something we hope to get done before the end of this current cycle
10:34:15 cdent bhagyashris: if you mean something else, what is it?
10:35:25 bhagyashris cdent: yeah i want to track nfs share as a resource provider.
10:36:35 cdent bhagyashris: there's a blueprint for that here, but progress is stalled while we work some other things out first: https://blueprints.launchpad.net/nova/+spec/shared-resources-pike
10:37:24 bhagyashris cdent: ok. means on current master we can not configure the shared disk resource provider for multinode set up right?
10:37:24 cdent you could, if you wanted, track the nfs share as a resource provider and manage its inventory with your own tooling, now, but that information wouldn't yet be used in scheduling decisions
10:37:31 cdent correct
10:37:41 bhagyashris cdent: ok i will go through the blueprint.
10:38:22 bhagyashris cdent: i look in to the blueprint regading the resource pool but not sure that the implementation is completed.
10:38:40 bhagyashris cent: thank you for information
10:44:31 openstackgerrit jichenjc proposed openstack/nova master: use plain routes list for hypervisor endpoint instead of stevedore https://review.openstack.org/459235
10:49:30 openstackgerrit jichenjc proposed openstack/nova master: Use plain routes list for limits endpoint instead of stevedore https://review.openstack.org/458805
10:49:30 openstackgerrit jichenjc proposed openstack/nova master: Use plain routes list for flavors-access endpoint instead of stevedore https://review.openstack.org/456589
10:49:31 openstackgerrit jichenjc proposed openstack/nova master: Use plain routes list for '/servers' endpoint instead of stevedore https://review.openstack.org/445864
10:49:31 openstackgerrit jichenjc proposed openstack/nova master: Use plain routes list for flavor endpoint instead of stevedore[1] https://review.openstack.org/456549
10:49:32 openstackgerrit jichenjc proposed openstack/nova master: Use plain routes list for hosts endpoint instead of stevedore https://review.openstack.org/459231
10:49:32 openstackgerrit jichenjc proposed openstack/nova master: Use plain routes list for '/os-aggregates' endpoint instead of stevedore https://review.openstack.org/456825
10:49:33 openstackgerrit jichenjc proposed openstack/nova master: Use plain routes list for flavors-extraspecs endpoint instead of stevedore https://review.openstack.org/456585
10:49:34 openstackgerrit jichenjc proposed openstack/nova master: Use plain routes list for '/os-keypairs' endpoint instead of stevedore https://review.openstack.org/456478
10:49:35 openstackgerrit jichenjc proposed openstack/nova master: use plain routes list for hypervisor endpoint instead of stevedore https://review.openstack.org/459235
12:00:58 openstackgerrit Moshe Levi proposed openstack/os-vif master: HW offload support for openvswitch https://review.openstack.org/398277
12:00:59 openstackgerrit Moshe Levi proposed openstack/os-vif master: add documentation for vif plug ovs https://review.openstack.org/459258
12:14:59 openstackgerrit jichenjc proposed openstack/nova master: Add description for /consoles https://review.openstack.org/459266
12:25:45 openstackgerrit Takashi NATSUME proposed openstack/nova master: List/show all server migration types https://review.openstack.org/430608
12:43:26 mriedem lyarwood: i replied in https://review.openstack.org/#/c/456896/ - i'm not sure i get your concern though
12:45:08 lyarwood mriedem: morning, yeah I missed the optimisation, I just assumed we were doing this to allow non-local connectors to be passed in as a kwarg that we would default to None when we wanted to use the local connector.
12:49:14 mriedem lyarwood: when i looked at the change that were passing a connector in, none of them had a local connector
12:49:28 mriedem *was
12:52:12 lyarwood mriedem: into _terminate_volume_connections? Sorry I don't follow.
12:52:44 mriedem earlier version of the patch https://review.openstack.org/#/c/456896/3/nova/compute/manager.py@3615
12:52:54 mriedem was going out of it's way to get the connector and then pass it in to justify the kwarg
12:52:56 mriedem i don't know why
12:53:17 mriedem so until we actually need a connector=None kwarg on _terminate_volume_connections, i've omitted that
12:53:47 lyarwood mriedem: yeah that didn't make sense but that's the local compute connector, thus my confusion above ;)
12:54:07 lyarwood mriedem: and yeah, until we have a stashed connector to pass in the kwarg doesn't make sense
12:54:32 lyarwood mriedem: I just missed the optimisation and assumed we wanted to add the kwarg early
12:55:04 lyarwood anyway, back to these LM failures on stable
12:55:26 mriedem lyarwood: so are you still -1 on https://review.openstack.org/#/c/456896/ ?
12:55:36 lyarwood mriedem: no, I'll clean that up now
12:56:05 mriedem thanks
12:58:14 mriedem jgriffith: when you're around, i had some questions marked with TODOs in the swap volume change for using the new cinder attachment APIs https://review.openstack.org/#/c/456971/4/nova/compute/manager.py
12:58:30 mriedem like, will deleting an attachment mess up migrate_volume_completion on the cinder side?
12:59:10 mriedem https://review.openstack.org/#/c/456971/4/nova/compute/manager.py@4993 and https://review.openstack.org/#/c/456971/4/nova/compute/manager.py@5017 specifically
13:00:29 lyarwood mdbooth: https://review.openstack.org/#/c/458807/ updated if you have anytime this afternoon
13:00:36 lyarwood kashyap: ^ also
13:00:55 lyarwood kashyap: could you also take a look at https://review.openstack.org/#/c/458854/1
13:01:04 kashyap lyarwood: Struggling with something else at the moment :-(

Earlier   Later