| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-06-23 | |||
| 17:28:05 | sean-k-mooney | efried: thanks im trying to think how i will go about the transfroamtion for modeling nuam in placement and i want a nice way to visualise the tree | |
| 17:32:25 | openstackgerrit | Stephen Finucane proposed openstack/nova master: hardware: Remove '_numa_fit_instance_cell_with_pinning' https://review.opendev.org/714703 | |
| 17:32:25 | openstackgerrit | Stephen Finucane proposed openstack/nova master: hardware: Invert order of NUMA topology generation https://review.opendev.org/714701 | |
| 17:32:26 | openstackgerrit | Stephen Finucane proposed openstack/nova master: hardware: Tweak the 'cpu_realtime_mask' handling slightly https://review.opendev.org/461456 | |
| 17:32:26 | openstackgerrit | Stephen Finucane proposed openstack/nova master: hardware: Allow 'hw:cpu_realtime_mask' to be omitted https://review.opendev.org/737026 | |
| 17:33:08 | efried | I thought gibi_off wrote some kind of tool to prettyprint those trees. | |
| 17:33:17 | sean-k-mooney | maybe | |
| 17:33:37 | efried | I don't have it in front of me, but looking provider_tree.py for that iterator function. | |
| 17:33:53 | efried | It's not __iter__ but I'm pretty sure I made a getter that gives them to you in a predictable order. | |
| 17:33:57 | sean-k-mooney | it looks like its doing a depth frist traversal from the root with childern lexically sorted by uuid | |
| 17:35:05 | sean-k-mooney | efried: ya its fine ill figure it out. i might make it iterable jsut to make it spelper and immperment __repr__ for provier | |
| 17:35:24 | sean-k-mooney | *simpler and implement | |
| 17:51:49 | sean-k-mooney | efried: so ya i just need to add | |
| 17:51:50 | sean-k-mooney | def __iter__(self): | |
| 17:51:53 | sean-k-mooney | for uuid in self.get_provider_uuids(): | |
| 17:51:55 | sean-k-mooney | yield self._find_with_lock(uuid) | |
| 17:52:42 | sean-k-mooney | but i might invert the logic an make get_provier_uuids use the iterator | |
| 17:53:15 | sean-k-mooney | it would avoid the need to call fine_with_lock twice once in get_provier_uuids and then again in the iterator | |
| 17:53:29 | sean-k-mooney | thanks for the pointer | |
| 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 | |