Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-10-18
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
12:23:53 sean-k-mooney pooja_jadhav: hi
12:24:33 pooja_jadhav sean-k-mooney: 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 instances. (1 instances repeated again). Can you guide me for the same?
12:26:51 jangutter sean-k-mooney: I tried looking for any os-vif patches in the gate and it seemed to have silently disappeared.
12:27:07 sean-k-mooney looking at it. depending on what _fake_instance does it looks like this should create tenahts*servers fake instance objecst
12:27:55 sean-k-mooney jangutter: ok well its there now http://zuul.openstack.org/status if you put 611017 in the filter
12:28:26 sean-k-mooney sometimes it takes a minute for it to post back after it leaves the queue
12:29:32 sean-k-mooney pooja_jadhav: was there somthing in partcaller that you were confusted by regarding https://github.com/openstack/nova/blob/master/nova/tests/unit/api/openstack/compute/test_simple_tenant_usage.py#L135-L143
12:31:24 pooja_jadhav sean-k-mooney: sorry, I am not getting what u mean to say
12:32:09 sean-k-mooney pooja_jadhav: https://github.com/openstack/nova/blob/master/nova/tests/unit/api/openstack/compute/test_simple_tenant_usage.py#L136-L143 is is construcint an InstanceList by initalisint the objects filed with a list comprehention
12:32:59 sean-k-mooney it is first calulating a rag by multipliying tenants by server then for each x in that range it is calling _fake_instance
12:33:07 pooja_jadhav sean-k-mooney: the issue i am facing like, I am creating 2 instances then in the simple tenant usage api should give me usgaes for that 2 instances only. but I can see 4 instance instead
12:34:01 pooja_jadhav correct
12:34:34 pooja_jadhav SERVERS = 5 and TENANTS = 2 (it should create 10 instances)
12:34:39 sean-k-mooney TENANTS and SERVERS are not paramaters to the function
12:34:41 pooja_jadhav correct?
12:34:43 sean-k-mooney yes
12:35:07 pooja_jadhav but when I see the instanceList, in that I can see 20 instances
12:35:25 pooja_jadhav 1 instance is repeating again (twice)
12:35:37 pooja_jadhav for the existing test cases only
12:36:04 sean-k-mooney can yo point me to a failing test?

Earlier   Later