| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-10-18 | |||
| 01:35:23 | openstackgerrit | Naichuan Sun proposed openstack/nova master: xenapi(N-R-P):Get vgpu info from `allocations` https://review.openstack.org/521717 | |
| 01:36:14 | openstackgerrit | Naichuan Sun proposed openstack/nova master: xenapi(N-R-P):Get vgpu info from `allocations` https://review.openstack.org/521717 | |
| 01:36:40 | openstackgerrit | Naichuan Sun proposed openstack/nova master: xenapi(N-R-P): support compute node resource provider update https://review.openstack.org/521041 | |
| 01:37:21 | openstackgerrit | Naichuan Sun proposed openstack/nova master: xenapi(N-R-P): support compute node resource provider update https://review.openstack.org/521041 | |
| 01:37:47 | openstackgerrit | Naichuan Sun proposed openstack/nova master: os-xenapi(n-rp): add traits for vgpu n-rp https://review.openstack.org/604269 | |
| 01:59:35 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Merge image_size extension response into image view builder https://review.openstack.org/606845 | |
| 01:59:56 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Remove the caching the resource on Request object https://review.openstack.org/609403 | |
| 02:00:17 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Remove more code related to extensions and testing https://review.openstack.org/607088 | |
| 02:01:04 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Remove the extensions framework from wsgi.py https://review.openstack.org/607092 | |
| 02:01:42 | gmann | stephenfin: alex_xu ^^ rebased the series, need to +A again. | |
| 06:58:01 | openstackgerrit | Tetsuro Nakamura proposed openstack/nova-specs master: Spec: Support filtering by forbidden aggregate https://review.openstack.org/603352 | |
| 08:12:03 | gibi | Kevin_Zheng: I've responded to you in https://review.openstack.org/#/c/605785 | |
| 08:13:13 | Kevin_Zheng | gibi, Oh, yes, I will check ASAP, I was busy on something else, these days, sorry for the late response | |
| 08:13:36 | gibi | Kevin_Zheng: no problem, take your time. :) | |
| 08:18:23 | bauzas | oh oops my manners | |
| 08:18:26 | bauzas | good morning Novaz | |
| 08:18:37 | gibi | bauzas: good morning | |
| 08:24:03 | Kevin_Zheng | gibi, I still don't get the reason for NoValidHost exception | |
| 08:25:11 | Kevin_Zheng | I got the point you illustrate in both case 1 and 2 | |
| 08:25:31 | gibi | Kevin_Zheng: bottom line, nova cannot always detect if the server would need complex allocation on the destination. When nova cannot detect that Nova cannot raise other than NoValidHost as that is the generic exception used when placement allocation fails | |
| 08:26:03 | gibi | Kevin_Zheng: so there will be always cases when nova raise NoValidHost because of complex allocation would be needed | |
| 08:27:27 | gibi | Kevin_Zheng: therefore I think it will be even more confusing to raise NoValidHost is some case and ComplexAllocationNotSupported exception in other cases when both situations has the same root casuse, the need for the complex allocation | |
| 08:28:59 | Kevin_Zheng | OK, I got your point | |
| 08:29:30 | gibi | Kevin_Zheng: I can inform the user properly in half of the cases :/ | |
| 08:30:47 | Kevin_Zheng | Hmm, but maybe it will still be miss leading, as an user, I can see that I still have resources in the cloud | |
| 08:30:56 | gibi | Kevin_Zheng: this is basically a chiken-and-egg problem. The need of complex allocation on the destination can only be detected in every case if placement a_c is called. But force flag is defined in a way that it forbids calling the scheduler and placement | |
| 08:30:58 | Kevin_Zheng | but you tell me that there is no valid host? | |
| 08:31:29 | gibi | Kevin_Zheng: only if you specify the force flag | |
| 08:31:39 | gibi | Kevin_Zheng: the root of the problem is the definition of the force flag | |
| 08:32:21 | gibi | Kevin_Zheng: it forces (sic) nova to decide without the scheduler. But when we introduced placement in the picture nova lost the possibility to decide without consulting placement | |
| 08:33:17 | Kevin_Zheng | Hmm, there is a log, but the logs may only be available for ``operators``, if we had ``admins`` that can use force flag, this might still be confusing? | |
| 08:34:14 | gibi | Kevin_Zheng: there is no specific log in case #2. In case #2 nova tries to blind copy the flat soruce allocation to the dest but on the dest the root RP does not have enough resources therefore it is a NoValidHost | |
| 08:35:05 | gibi | Kevin_Zheng: it is indistinguishable from the case when the dest would allow flat alloaction but we run out of resources on the dest | |
| 08:35:10 | Kevin_Zheng | Hmm, thats true | |
| 08:35:29 | Kevin_Zheng | Ok, I'm convienced | |
| 08:35:31 | Kevin_Zheng | :) | |
| 08:39:38 | gibi | Kevin_Zheng: I understand that it is not a good situation from the user perspective. But force flag cannot be supproted any more as it is defined today. This is why I proposed to remove that flag in the future | |
| 08:41:16 | Kevin_Zheng | yes, I understand, but I think it might be very widely used for admins, as you mentioned, it has already been discussed, and it is free to propose better solutions, I think I will try to dig deeper. | |
| 08:44:19 | gibi | Kevin_Zheng: in the ML post I tried to give alternatives http://lists.openstack.org/pipermail/openstack-dev/2018-October/135551.html | |
| 08:44:55 | gibi | Kevin_Zheng: option #D) would be one way out but that would be bad from other perspective (inconsisten resource allocation) | |
| 09:04:49 | sean-k-mooney | o/ | |
| 09:25:36 | jangutter | sean-k-mooney: in your absence, it was discovered that random failures in the gate uncovered a bug: https://review.openstack.org/#/c/611017 | |
| 09:31:41 | sean-k-mooney | jangutter: oh looking | |
| 09:32:28 | sean-k-mooney | jangutter: am.. that should not chage anything | |
| 09:32:58 | sean-k-mooney | the real code check that its sys.platform != 'nt' | |
| 09:33:17 | sean-k-mooney | what you call the linux one has no effect on the code | |
| 09:34:01 | sean-k-mooney | although may be im think of os.name | |
| 09:35:12 | sean-k-mooney | oh i see the bug... | |
| 09:35:38 | jangutter | sean-k-mooney: yeah, it basically turned the gate into a handy fuzzer. | |
| 09:35:51 | sean-k-mooney | ya ill quick approve that. its not the first time i have seen people assign directly to a module before and override things | |
| 09:36:53 | jangutter | sean-k-mooney: the follow-on is a bit hinky, not sure what hyperv should do: does it need to delete anything, or is it just a handle that disappears when the port gets deleted? | |
| 09:37:02 | sean-k-mooney | jangutter: ya there was anothter patch in the past where someone on my team assigned a mock to a module then then sepnt a day trying to figure out why random test were failing | |
| 09:38:17 | jangutter | sean-k-mooney: I hit the trifecta, I triggered this randomly on macos, where the error appeared to say: you can't run this linux command on Windows! | |
| 09:38:56 | sean-k-mooney | jangutter: well osx is not supported at all but ill ignore that | |
| 09:39:49 | sean-k-mooney | so on the delete port thing i was personally thinking of removeing that call from the ovs-lib | |
| 09:40:38 | sean-k-mooney | jangutter: that said there is a delete_netdev flag so im ok with you patch as is for now | |
| 09:41:24 | jangutter | sean-k-mooney: yah, you know anyone on hyperv able to tell if it's the right thing to do (tm)? | |
| 09:41:25 | sean-k-mooney | i do not really like the depency that delete_netdev adds between ovsdb module and linux_networking | |
| 09:41:56 | sean-k-mooney | jangutter: well iptools and pyroute2 do not work on windows so i would think its correct :) | |
| 09:42:02 | sean-k-mooney | eg your change | |
| 09:42:55 | jangutter | sean-k-mooney: yeah, i also would like it if the ovsdb lib would be "thinner" and just do ovsdb things. | |
| 09:43:12 | sean-k-mooney | jangutter: that is what it is ment to do | |
| 09:43:38 | sean-k-mooney | other then this one call to delete the nedev device i dont think it does more today | |
| 09:43:55 | jangutter | sean-k-mooney: the set mtu thingy too. | |
| 09:44:09 | sean-k-mooney | well that is tricky but we can split it | |
| 09:44:20 | sean-k-mooney | for vhost user that has to be done via the ovsdb | |
| 09:45:34 | sean-k-mooney | i have no issue with making it explict per vif type however and invoking it in the ovs.py file | |
| 09:45:44 | jangutter | sean-k-mooney: yep, any abstraction eventually becomes leaky. a working fix is better than a perfect fix that's never implemented. | |
| 09:46:14 | sean-k-mooney | ideally the ovsdb module should be cross plathform | |
| 09:46:43 | jangutter | sean-k-mooney: and pushing out the complexity towards the plugin "feels" right in my opinion. | |
| 09:47:29 | sean-k-mooney | jangutter: so on a related topic. i want to improve the testing in os-vif. i will hopefully get around to adding a linux bridge job and mayboe an ovs-iptables job or ovn. | |
| 09:48:29 | sean-k-mooney | we talked in the past about a agilo ovs ci do you have one running on your plugin? | |
| 09:49:17 | sean-k-mooney | if so it might be nice to trigger it on a restited set of os-vif files also | |
| 09:49:26 | jangutter | sean-k-mooney: heh, in theory yes, in practice it's been busted for ages. | |
| 09:49:37 | sean-k-mooney | ok :) | |
| 09:50:02 | jangutter | sean-k-mooney: (on expanding the tests, is this more or less in the right direction for "future os-vif"? https://review.openstack.org/#/c/610636/ ) | |
| 09:54:40 | sean-k-mooney | i was just opening that :) | |
| 09:57:48 | sean-k-mooney | jangutter: so one change to that interface that i think we will need to do is be able to pass in the tree and then filter it | |
| 09:58:31 | jangutter | sean-k-mooney: you mean something like https://github.com/openstack/nova/blob/kilo-eol/nova/objects/instance.py#L257 | |
| 09:59:00 | sean-k-mooney | no | |
| 09:59:43 | jangutter | sean-k-mooney: ah, I see what you mean. Rather than self-editing the object, return a new one with the filtered fields? | |
| 10:00:23 | sean-k-mooney | yes or rather host_info would retrun an unfiltered tree and then we would have a sperate filter function | |
| 10:01:03 | sean-k-mooney | the reason for this is i think we will want to have nova call host info and then filter by what the hypervior can support then serialser it and send it to neutron | |
| 10:01:09 | jangutter | sean-k-mooney: I had the same thought, it feels dirty to self-edit. | |
| 10:01:39 | sean-k-mooney | then neutron will want to filter it again and select a vif type from what is left | |
| 10:01:53 | jangutter | sean-k-mooney: filter should be a static function, not a member function. | |
| 10:03:25 | sean-k-mooney | ya proably it could be a class function that take steh tree as the second argument but a static fucntion would work just as well | |
| 10:03:28 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (3) https://review.openstack.org/574104 | |
| 10:03:47 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (4) https://review.openstack.org/574106 | |
| 10:04:02 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (5) https://review.openstack.org/574110 | |
| 10:05:15 | jangutter | sean-k-mooney: cool, will refactor the refilter. | |
| 10:06:12 | sean-k-mooney | :) cool the main issue is this part of the api was actully just a poc that was cerated without really thinking about how it would be used | |
| 10:09:28 | jangutter | sean-k-mooney: yep, and I realised while doing Jay's proposal for the offload metadata that if I don't work on this, it's going to result in another poor idiot thinking about this later. | |
| 10:12:09 | sean-k-mooney | jangutter: ya so this is all laying the ground work for doing the negciation likely in T | |
| 10:12:44 | sean-k-mooney | we could try and start it in Stein but i think that would be too tight to get the nova and neutron work done also | |
| 10:29:46 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Use oslo_db.sqlalchemy.test_fixtures https://review.openstack.org/609352 | |
| 11:36:01 | pooja_jadhav | hi team, I have some doubt in the https://github.com/openstack/nova/blob/master/nova/tests/unit/api/openstack/compute/test_simple_tenant_usage.py#L135-L143.. In this they are trying to create 10 instances but when I have debug the code, I can see 20 istances. (1 instances repeated again). Can anyone guide me for the same? | |
| 11:54:03 | openstackgerrit | Martin Midolesov proposed openstack/nova master: Implementing graceful shutdown. https://review.openstack.org/608704 | |
| 12:23:31 | pooja_jadhav | sean-k-mooney: Hi | |
| 12:23:49 | sean-k-mooney | jangutter: fyi your patch is still in the gate which is why the next patach has the -2 since its not merged yet | |