Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-06-24
07:33:30 brinzhang_ it's not come from nova service log, it's print by docker
07:35:26 gibi_off check the output of the systemctl status for the docker service
07:42:07 brinzhang_ gibi_off: This problem does not occur every time you evacuate. It happens occasionally, but it has been encountered twice.
07:43:30 brinzhang_ gibi_off: we will try to make the TasksMax setting get bigger, then try to test
07:43:48 brinzhang_ gibi_off: thanks for your advice
09:24:00 stephenfin bauzas: think you could look at https://review.opendev.org/#/c/714700/ ? It's the last patch I've authored in that series, so I can take it from there
09:24:12 bauzas stephenfin: ack, clicks
10:25:17 nightmare_unreal is migration ( both cold and live migration) are of more I/O bound task or more CPU bound ?
10:25:44 sean-k-mooney nightmare_unreal: it depend on what you mean by io but io
10:26:23 sean-k-mooney nightmare_unreal: the more the guest dirties memeory the longer it will take and that time is bounded by the bandwidth you have to copy the data over
10:26:36 nightmare_unreal i mean input / ouput. What I was thinking was since we move lots of data ( essentially a whole VM) it is heavy work right ?
10:26:55 nightmare_unreal ah okay
10:27:25 sean-k-mooney copying the disk is actully relitivly simple and not needed if its boot from volume
10:27:32 sean-k-mooney or on shared storage
10:27:39 sean-k-mooney its the ram that is a problem
10:27:59 sean-k-mooney the virtual cpu state is pretty small so that is not hard to transfer
10:28:37 sean-k-mooney if a vm is under heavy load you should expect that the live migration will never finish unless you enable auto convergence and/or post copy
10:28:53 nightmare_unreal ah okay !!
10:29:17 sean-k-mooney auto convergnece after an inital timeout progressivly starts micro pausing the vm for long and longer intervals
10:29:41 nightmare_unreal and this is all managed by nova itself ?
10:29:53 sean-k-mooney no its all manage by qemu/libvirt
10:29:53 nightmare_unreal I mean user won't have to do these checks right
10:30:01 nightmare_unreal ah okay
10:30:12 nightmare_unreal understood
10:30:18 sean-k-mooney there are nova config options for auto convergancve and post copy
10:30:31 sean-k-mooney we just tell libvit that it can use them and it tells qemu
10:30:43 sean-k-mooney i think they are off by default
10:30:49 nightmare_unreal okay
10:31:04 nightmare_unreal I will read some more docs on it to get better idea
10:31:06 nightmare_unreal Thanks sean-k-mooney
10:31:24 sean-k-mooney https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.live_migration_permit_post_copy
10:31:30 sean-k-mooney https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.live_migration_permit_auto_converge
10:31:39 sean-k-mooney personally i would set both to true
10:32:00 sean-k-mooney just be aware if you have post copy enabled and there is a netwrok partion during the migration it will crash the vm
10:32:24 nightmare_unreal okay :) . I will note that
10:32:25 sean-k-mooney i dont think that is a signifcant enough risk to warrent disabling it but that is something you should decied
10:33:15 nightmare_unreal okay. mnaybe after seeral trials and error i will find out
10:33:23 sean-k-mooney nightmare_unreal: cool as i said i personally recommend turning both on to ensure live migration actully eventually finish and it should be faster.
10:33:29 nightmare_unreal what suits best for my env
10:33:40 nightmare_unreal thanks
10:36:16 sean-k-mooney oh i guess you need to change https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.live_migration_timeout_action to force_complete too
10:36:43 sean-k-mooney to get post copy to work. its noted in the config docs but i tought that was the default value not abort
12:41:45 sean-k-mooney stephenfin: can i pick your brain for a sec. its a dumb question but im interseted in what you expect.
12:41:53 stephenfin sure
12:42:40 sean-k-mooney stephenfin: if you have a tree and you do "for x in tree: do_stuff(x)" do you expect that to iterate over every node in the tree or over the roots?
12:43:17 stephenfin I'd expect it to iterate over the immediate children
12:43:28 stephenfin for grandchildren, you'd have to nest the for loop
12:43:31 stephenfin IMOP
12:43:33 stephenfin *IMO
12:44:28 sean-k-mooney so that is one way to do it yes. and in that case if i printed the child node woudl you expect it to print just its data or the data of its childeren
12:44:39 sean-k-mooney *also the data of its childern
12:44:59 stephenfin depends on how you have __repr__ implemented for the Node class
12:45:17 stephenfin You could do either, so long as it's consistent
12:45:39 stephenfin might be worth looking at what xml.etree.ElementTree does (and the lxml.etree equivalent)
12:45:39 sean-k-mooney so that the thing im currently implmeneting an __iter__ and __repr__ for ProviderTree and _Provider
12:46:21 sean-k-mooney stephenfin: so i know the lark parser lib chose to make the tree iterator, iterate over every node in the tree in a fixed order
12:46:30 sean-k-mooney not just the child nodes
12:46:48 sean-k-mooney and so if you pirnt the node they just print them selves not there childern
12:46:49 stephenfin that seems weird to me
12:46:56 stephenfin but it really depends on how you plan to use it
12:47:26 sean-k-mooney let me see what lxml does
12:47:59 sean-k-mooney i have implemetned both way and swap back and forward between what i think is correct.
13:04:18 sean-k-mooney stephenfin: they support both but in a slightly weird way https://lxml.de/tutorial.html#tree-iteration
13:05:19 stephenfin sean-k-mooney: what should I be looking at?
13:05:27 stephenfin I can only see a single root node with leaves
13:05:31 sean-k-mooney __iter__ on the element class iterates the childern __iter__ on the ElementTree class iterates all elements in the tree and the elemnet objects also have a .iter() function to do tree iteration on the elements
13:07:36 stephenfin Hmm, I'm not seeing that
13:07:42 stephenfin in the link you provided
13:08:15 sean-k-mooney "where you want to recursively traverse the tree and do something with its elements, tree iteration is a very convenient solution. Elements provide a tree iterator for this purpose. It yields elements in document order, i.e. in the order their tags would appear if you serialised the tree to XML:"
13:08:47 sean-k-mooney so the elements.itor() function is recursive over the child nodes and __iter__ is not recursive
13:09:24 sean-k-mooney so i think the behvior i want is __iter__ for ProviderTree should yeild all the provider in the tree in depth first order
13:09:50 sean-k-mooney but __iter__ on the provider will just yeild its imideate childeren
13:09:57 sean-k-mooney if i was to follow there patteren
13:12:45 stephenfin ah, so it's just a depth-first search
13:13:01 sean-k-mooney depth first traversal but yes
13:13:16 stephenfin *traversal, yeah
13:13:38 sean-k-mooney you could do it breathfirst but we already do depth first for get_provider_uuids
13:14:14 stephenfin what you're suggestions works for me, anyway
13:14:29 stephenfin different behavior on ProviderTree vs provider
13:15:23 sean-k-mooney ya i expect tree to have tree iteration and i guess node to have iteration of just there direct childern also make sense
13:15:42 sean-k-mooney stephenfin: etree makes there element behave like python lists
13:16:14 sean-k-mooney and i think that behvior makes sense for proviers but the ProviderTree shoudl act like a tree
13:37:22 openstackgerrit Dan Smith proposed openstack/nova master: DNM: Try to make a glance multistore job https://review.opendev.org/734184
14:37:55 openstackgerrit Dan Smith proposed openstack/nova master: Make libvirt able to trigger a backend image copy when needed https://review.opendev.org/656998
14:37:55 openstackgerrit Dan Smith proposed openstack/nova master: Plumb image import functionality through our glance module https://review.opendev.org/731550
14:37:56 openstackgerrit Dan Smith proposed openstack/nova master: DNM: Try to make a glance multistore job https://review.opendev.org/734184
14:37:56 openstackgerrit Dan Smith proposed openstack/nova master: WIP: Add libvirt RBD configuration doc https://review.opendev.org/731577
14:38:33 dansmith melwitt: had to rebase, can you re-+W those two? ^
14:56:23 aarents Hi, what the meaning of "DNM:" in commit title ?
14:58:12 bauzas aarents: Do Not Merge
14:58:38 aarents bauzas: k thks
14:59:01 bauzas np
15:02:42 melwitt dansmith: will do
15:27:56 stephenfin bauzas: friendly reminder on https://review.opendev.org/#/c/714700/, if you've time :)
15:28:38 bauzas stephenfin: yup, haven't forgotten but I looked at the whole series to refresh my mind
15:30:03 dansmith melwitt: thanks
15:42:51 openstackgerrit Ghanshyam Mann proposed openstack/nova stable/stein: Make greande jobs n-v for EM and oldest stable https://review.opendev.org/737332
15:59:48 bauzas stephenfin: question before I leave https://review.opendev.org/#/c/714697/10/nova/objects/instance_numa.py@213
16:00:39 bauzas I do understand this could be silly to have more than one policy, but should we have a kind of nova status upgrade check preventing it ?
16:37:07 stephenfin bauzas: It's not just silly, it's impossible

Earlier   Later