Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-04-23
15:44:16 mriedem that 1.0 in the ec2 route versions must have been for openstak
15:44:19 mriedem *openstack
15:56:16 mriedem or i guess it was 1.0 for ec2?
16:08:05 mriedem ooo snap i found the 2010.1 code on launchpad
20:48:39 openstackgerrit OpenStack Proposal Bot proposed openstack/nova master: Updated from global requirements https://review.openstack.org/458834
22:31:34 openstackgerrit Matt Riedemann proposed openstack/nova-specs master: Update cinder-new-attach-apis spec for begin_detaching https://review.openstack.org/459134
#openstack-nova - 2017-04-24
00:51:08 openstackgerrit Takashi NATSUME proposed openstack/nova master: api-ref: Parameter verification for servers-actions (2/4) https://review.openstack.org/455568
00:51:59 openstackgerrit Takashi NATSUME proposed openstack/nova master: api-ref: Parameter verification for servers-actions (3/4) https://review.openstack.org/455570
00:52:10 openstackgerrit Takashi NATSUME proposed openstack/nova master: api-ref: Parameter verification for servers-actions (4/4) https://review.openstack.org/455573
00:52:31 openstackgerrit Takashi NATSUME proposed openstack/nova master: api-ref: Example verification for servers-actions.inc https://review.openstack.org/454565
00:55:42 openstackgerrit Matt Riedemann proposed openstack/nova master: WIP: Add Cinder v3 detach to swap_volume https://review.openstack.org/456971
00:55:43 openstackgerrit Matt Riedemann proposed openstack/nova master: cinder: add attachment_update method https://review.openstack.org/459113
00:55:43 openstackgerrit Matt Riedemann proposed openstack/nova master: cinder: add attachment_create method https://review.openstack.org/459111
00:57:22 openstackgerrit Matt Riedemann proposed openstack/nova master: WIP: Add Cinder v3 detach to swap_volume https://review.openstack.org/456971
01:47:02 openstackgerrit Zhenyu Zheng proposed openstack/nova master: Rework descriptions in os-hypervisors https://review.openstack.org/452030
02:58:06 openstackgerrit Takashi NATSUME proposed openstack/nova master: Avoid forcing translation on logging calls https://review.openstack.org/413876
03:08:00 openstackgerrit Zhenyu Zheng proposed openstack/nova master: Trivial Fix a typo https://review.openstack.org/459149
05:22:01 openstackgerrit Michael Still proposed openstack/nova master: First attempt at adding a privsep user to nova. https://review.openstack.org/459166
06:59:15 openstackgerrit Zhenyu Zheng proposed openstack/nova master: Rework descriptions in os-hypervisors https://review.openstack.org/452030
07:19:03 bhagyashris Hi all, I need some guidance regarding, configuration: Is it possible to set single resource provider in multinode setup for nfs backend? How should I configure the single resource provider in multinode environment which uses the nfs backend?
07:23:01 openstackgerrit Béla Vancsics proposed openstack/nova master: Transform instance.trigger_crash_dump notification https://review.openstack.org/396225
08:04:20 openstackgerrit jichenjc proposed openstack/nova-specs master: Add os-quota-class-sets-query-update https://review.openstack.org/459185
08:26:24 moshele sfinucan: hi
08:26:32 sfinucan moshele: Heya
08:28:07 moshele sfinucan: regarding https://review.openstack.org/#/c/398277/ so I am not sure that vif_type is the best place to document the ovs plugin
08:29:55 sfinucan moshele: No? Would there be somewhere better suited?
08:31:45 moshele sfinucan: vif_type describe the version objects of the os-vif. I guess we should have also documentation per plugin ovs and lb
08:34:03 moshele sean-k-mooney: what do you think ^
08:34:14 johnthetubaguy there is the longer term plan around os-vif type binding
08:34:37 johnthetubaguy I was catch up with kevinbenton about that on friday I think
08:35:07 moshele can you point me to the discussion?
08:35:37 openstackgerrit jichenjc proposed openstack/nova-specs master: Add os-quota-class-sets-query-update https://review.openstack.org/459185
08:36:32 johnthetubaguy moshele: the wider context is implement the vif binding negotiation thing in the original os-vif spec, maybe thats not too relevant here, except for the versioning
08:39:10 moshele johnthetubaguy: ok I will read the os-vif spec
08:39:48 sfinucan moshele: The main thing I was looking for was a comparison of that particular VIF type to other VIF types
08:39:53 sfinucan I took a stab at documenting a glossary, but that doesn't really solve the problem here
08:40:02 sfinucan So if that's in the form of a new doc, so be it
08:40:33 johnthetubaguy sfinucan: docs are a good point here, I think that is slowing down the discussions with neutron
08:41:01 johnthetubaguy there is something that Nova calls to inspect the host to say what is supported, I guess we have to check the kernel to see if this new feature is supported
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 abhi89 johnthetubaguy: i will try this out
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: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 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:24 bhagyashris cdent: ok. means on current master we can not configure the shared disk resource provider for multinode set up right?
10:37:31 cdent correct
10:37:41 bhagyashris cdent: ok i will go through the blueprint.

Earlier   Later