Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-05-13
11:09:23 gibi sean-k-mooney: sure, I'm not talking about evac specially, but all the missing / unsupported server operation in general.
11:09:45 sean-k-mooney brinzhang_: well it was more just completeing the list here https://review.opendev.org/#/c/715326/10/api-guide/source/accelerator-support.rst
11:09:51 huaqiang hi, I have a question I wonder if anyone can give me some comment or deliver a conclusion directly. Does it tolerate to loose some information in a process of 'versioned_object.obj_to_primitive'? especially generating a primitive dict in a lower version number.
11:10:01 sean-k-mooney everything except for live migrate should be doable
11:11:31 sean-k-mooney gibi: ya i was originally planning to submit a patch for each of them im unst unlikely to have time to do that this cycle. that said i might work on it on and off this cycle.
11:11:53 brinzhang_ sean-k-mooney, gibi: yeah, in accelerator-support.rst marked unsuport all need to be consider to support, as sean-k-mooney said except for live migrate
11:12:22 sean-k-mooney brinzhang_: suspend/resume and shelve/unshelve should be fairly simple to do
11:12:42 gibi brinzhang_: do you or the cyborg team will have bandwidth during V to work on adding support for the missing operations?
11:12:45 sean-k-mooney resize/coldmigreate needs a little more work but they are effectvly the same operation
11:13:30 brinzhang_ sean-k-mooney: got it ^
11:14:21 gibi huaqiang: if you generate a lower version dict then you need to drop the fields that was not present in that lower version. So that is a necessary loss of information. Other than that I think we tend to keep the information. I think dansmith is the best person to ask
11:14:47 brinzhang_ gibi: yes, we will, during V we will open block operation asap, but we should talked in PTG,
11:15:42 gibi brinzhang_: OK. Thanks. I just wanted to make sure that you and sean-k-mooney are in sync about who does what in V
11:16:19 sean-k-mooney brinzhang_: there should not be any gaps in cyborg by the way for the remaining ops
11:16:25 sean-k-mooney its all jus nova work
11:17:09 gibi brinzhang_: checked https://review.opendev.org/#/c/719720/ and I left one comment about the password length
11:17:10 sean-k-mooney suspend/resume just need to be exteded to hot unplug the acclerator on suspend and hot plug them on resume like we do for normla pci passtough or sriov devices
11:17:23 brinzhang_ gibi: I follow sean-k-mooney, many operation may I cannt test, because of limit the hard device
11:17:50 gibi brinzhang_: I hope we can add functional test cases for most of it.
11:17:52 sean-k-mooney sheleve need to delete the arq binding in shelve offload and it need to claim(in placmemnt) the acclerateor and bind arques on unshelve
11:18:36 sean-k-mooney gibi: we can test most of it with the fake dirver too
11:18:42 gibi cool
11:19:18 sean-k-mooney we might want to add some extra logging in placese to be extra sure or enhance it slightly so we have something observable
11:19:42 brinzhang_ sean-k-mooney: cool, thanks, I will try to test that scenario
11:20:04 sean-k-mooney e.g. adding or remvoing an xml comment for example instead of doing nothing so we can se the fake device "added" or "removed"
11:22:19 brinzhang_ sean-k-mooney: I add your said in my list, I will check these thing, e.g. log, and suspend/resume or shelve/unshelve
11:25:31 gibi lyarwood: hi! I see a lot of rescue failure in the lvm job http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22cannot%20be%20rescued%5C%22 is it a known issue?
11:25:39 huaqiang gibi: Got. so the 'obj_to_primitive' offers the capability to run, but not with the full object function.
11:25:57 sean-k-mooney huaqiang: its not that it does not have full fucntion
11:26:21 sean-k-mooney its more that any feature that depends on data only contained in a later version cannot be used
11:27:30 sean-k-mooney huaqiang: when you are backleveling object you baseically are restited to the feature set of the oldest code base invovled in the rpc
11:28:17 huaqiang I am think my design for 'mixed-instance', that is an instance mixed with dedicated cpus and shared cpus, when I deal with the compatibility 'instanceNUMATopology', maybe one choice is dropping the dedicated CPUs directly
11:28:22 sean-k-mooney there are some expctions to that but in generall we dont try to caluate the valuse in new codebases if the object was created in an older version
11:29:14 sean-k-mooney huaqiang: well there are two cases
11:29:30 huaqiang sean-k-mooney: pls
11:29:52 sean-k-mooney if a field existied in an older version but the value was not supported we raise an excpetion if you try to backlevel it
11:30:07 sean-k-mooney but if the filed does not exist we remove the filed
11:30:27 sean-k-mooney let me find an example quick
11:30:28 huaqiang yes...
11:30:57 sean-k-mooney https://github.com/openstack/nova/blob/master/nova/objects/image_meta.py#L194-L200
11:31:18 sean-k-mooney so in 1.22 we extended the hw_video_model filed
11:32:05 huaqiang Yes. raised an exception
11:32:05 sean-k-mooney if an object was created using one of the values that was only supported in 1.22+ we raise an excption
11:32:34 sean-k-mooney but for hw_time_hpet when it is backleveled it is dropped
11:32:40 sean-k-mooney so for your feature
11:32:56 sean-k-mooney we would raise an excpetion for the cpu policy
11:33:16 sean-k-mooney e.g. you would not be allowed to backevel an object with cpu_policy=mixed
11:33:39 huaqiang Yes. I agree
11:33:40 sean-k-mooney because that woudl result in incorrect behavior
11:33:52 huaqiang how about InstanceNUMACell
11:34:02 huaqiang the closest example is this:https://github.com/openstack/nova/blob/master/nova/objects/numa.py#L49
11:34:25 huaqiang It dropped the host 'pcpuset' directly
11:35:19 sean-k-mooney yes
11:35:36 huaqiang Not translate the pcpuset to exsiting cpuset
11:35:53 sean-k-mooney so for mixed cpus you should not need to modify the OVOs out side fo adding the new value for the cpu policy correct
11:36:17 sean-k-mooney we dont need to modify the host cell object
11:36:27 huaqiang I don't
11:36:33 brinzhang_ gibi: can you open this link http://people.redhat.com/pbonzini/qemu-test-doc/_build/html/topics/vnc_005fsecurity.html
11:36:50 sean-k-mooney so the allowed values of https://github.com/openstack/nova/blob/master/nova/objects/instance_numa.py#L59 will change
11:37:12 sean-k-mooney but the cpu_pinning_raw value can be used in both the dedicated or mixed case
11:37:23 sean-k-mooney in the dedicated case it will have an entry for all cpus
11:37:44 sean-k-mooney in the mixed case it will have a mapping only for the pinned cpus and the floating cpus will not be listed
11:38:01 gibi brinzhang_: yes. Now I see where the limit is coming from. Maybe link this in the spec
11:38:27 brinzhang_ gibi: Ok, I will add this to spec
11:38:33 gibi brinzhang_: cool, thanks!
11:38:54 huaqiang sean-k-mooney: yes. cpu_pinning_raw for pinned cpus only
11:39:37 sean-k-mooney so what you will need to do is add a line here https://github.com/openstack/nova/blob/master/nova/objects/instance_numa.py#L42
11:39:42 huaqiang sean-k-mooney: https://review.opendev.org/#/c/716267/5/nova/objects/instance_numa.py
11:40:01 sean-k-mooney which will raise an excpetion if you try to backlevel an object with the policy set to mixed and i think that is all
11:40:18 sean-k-mooney huaqiang: yep exactly
11:40:40 huaqiang For in 'obj_make_compatible' for version 1.6, we have choice to through a exception
11:41:27 huaqiang and we have another choice to ' primitive.pop('pcpuset', None)' in generating version prior to 1.5
11:41:38 huaqiang I am thinking which one is better
11:41:57 sean-k-mooney that the thing we dont have a choice
11:42:08 sean-k-mooney for 1.6 we have to raise an excption
11:42:21 sean-k-mooney if we dropped the value then we would cahgne form mixed to shared
11:42:28 sean-k-mooney that is wrong
11:42:53 huaqiang Yes. I don't allow change from a mixed to shared
11:42:59 huaqiang sound reasonable
11:43:20 sean-k-mooney i think what is being done for 1.5 and 1.6 in those patches is correct
11:44:26 huaqiang sean-k-mooney: Thanks
11:44:39 huaqiang It is clear for me.
11:45:48 huaqiang sean-k-mooney: another thing
11:46:07 huaqiang since v1.6 is not compatible with v1.5
11:46:09 huaqiang should be bump the major version number?
11:46:10 openstackgerrit Brin Zhang proposed openstack/nova-specs master: Re-proposes 'Proposal for a safer remote console with password authentication' https://review.opendev.org/719720
11:46:31 sean-k-mooney we dont really use the major version number
11:46:36 brinzhang_ gibi: done, thanks
11:46:37 huaqiang s/should be/ should we/
11:46:39 sean-k-mooney but we could i guess
11:47:02 sean-k-mooney that wone i would want dansmith to weigh in on as i dont know why we dont bump the major version
11:47:25 sean-k-mooney proably because its only conditionally incompatiable
11:47:28 huaqiang I'll leave it for revewer for designe
11:47:36 huaqiang s/designe/decision/
11:47:50 sean-k-mooney e.g. if you are using shraed or dedicated we can backlevel it
11:48:10 sean-k-mooney so since it not a hard incompatiablity we dont need to modify the major version
11:48:15 huaqiang it true.
11:48:40 huaqiang ok, thanks
11:49:15 openstackgerrit Takashi Natsume proposed openstack/nova master: Remove six.PY2 and six.PY3 https://review.opendev.org/726512
11:49:29 openstackgerrit Takashi Natsume proposed openstack/nova master: Remove six.add_metaclass https://review.opendev.org/726565

Earlier   Later