| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-06-23 | |||
| 18:01:16 | efried | sean-k-mooney: feel free to add me to review if you spin up something there. | |
| 18:03:14 | efried | Here's where that thing is used https://github.com/openstack/nova/blob/f1ebc15dfc8ffb7f23b2cb9879f0ca9376931a90/nova/scheduler/client/report.py#L1348-L1349 (and IIRC the reason it was written) | |
| 18:03:50 | efried | so whatever you change, please keep in mind that that ^ is going to run every periodic -- so don't slow it down too much :P | |
| 18:04:36 | sean-k-mooney | ya it should not be any slower | |
| 18:05:17 | sean-k-mooney | but sure ill add you to the review | |
| 18:07:51 | stephenfin | melwitt: could you hit this trivial requirements patch, please https://review.opendev.org/#/c/730960/ ? | |
| 18:25:04 | openstackgerrit | sean mooney proposed openstack/nova master: [WIP] make provider tree and proviers iterable https://review.opendev.org/737594 | |
| 18:25:28 | sean-k-mooney | efried: that is the version where i have not inverted the logic ^ | |
| 18:25:34 | sean-k-mooney | which im testign with http://paste.openstack.org/show/795116/ | |
| 18:29:39 | sean-k-mooney | which if i execute it looks like this http://paste.openstack.org/show/795117/ | |
| 18:31:19 | efried | ++ | |
| 18:32:04 | sean-k-mooney | i should be able to make the provider tee actully do indenting too but that the quick hack for now | |
| 19:22:01 | melwitt | gmann: did you see the author's reply on this patch? https://review.opendev.org/#/c/730960/1//COMMIT_MSG@9 | |
| 19:22:34 | gmann | melwitt: checking | |
| 19:27:09 | gmann | melwitt: i forgot to test it locally and if any things we need to adjust from jsonschema FormatChecker. let me do it and review again. thanks for reminder | |
| 19:27:23 | melwitt | gmann: sweet thanks | |
| 19:29:27 | melwitt | stephenfin: gmann is gonna review ^ again, there was a local test he wanted to do | |
| 20:15:21 | spatel | sean-k-mooney: hey! | |
| #openstack-nova - 2020-06-24 | |||
| 01:54:34 | openstackgerrit | Merged openstack/nova master: Cap jsonschema 3.2.0 as the minimal version https://review.opendev.org/730960 | |
| 02:27:16 | openstackgerrit | Merged openstack/nova master: Guard against missing image cache directory https://review.opendev.org/736964 | |
| 03:01:43 | openstackgerrit | Merged openstack/nova master: hardware: Update and correct typing information https://review.opendev.org/714694 | |
| 03:01:55 | openstackgerrit | Merged openstack/nova master: libvirt: Add typing information https://review.opendev.org/714695 | |
| 03:16:22 | openstackgerrit | Merged openstack/nova master: hardware: Add validation for 'cpu_realtime_mask' https://review.opendev.org/468203 | |
| 03:16:30 | openstackgerrit | Merged openstack/nova master: tests: Split instance NUMA object tests https://review.opendev.org/714696 | |
| 07:23:12 | brinzhang_ | Hello guys, has anyone encountered this problem with "GLib (gthread-posix.c): Unexpected error from C library during 'pthread_key_create': Resource temporarily unavailable. Aborting" | |
| 07:24:48 | brinzhang_ | it was happened when evacuate the instances, deployed the OpenStack R release on Centos7 | |
| 07:29:28 | gibi_off | brinzhang_: is this log from a nova service? Is that service has a task limit in the output of systemctl status ? | |
| 07:30:21 | gibi_off | brinzhang_: https://github.com/systemd/systemd/blob/ddb4b0d3eb57292c38a76f9b977f73cea15448fb/NEWS#L65-L68 | |
| 07:31:34 | brinzhang_ | gibi_off: Do you mean that the number of threads has reached the upper limit? | |
| 07:33:02 | gibi_off | brinzhang_: yeah, that could be a reason | |
| 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 | |