| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-03 | |||
| 09:31:52 | bauzas | in case people face the same problem, sdague explained the issue in http://lists.openstack.org/pipermail/openstack-dev/2017-September/122277.html | |
| 09:53:58 | openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/nova-specs master: Intel Fortville Dynamic Device Personalization (DDP) https://review.openstack.org/503001 | |
| 09:59:10 | openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/nova-specs master: Intel Fortville Dynamic Device Personalization (DDP) https://review.openstack.org/503001 | |
| 10:20:22 | openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/nova-specs master: Enable SR-IOV NIC offload feature discovery https://review.openstack.org/504895 | |
| 10:31:50 | openstackgerrit | Chris Dent proposed openstack/nova-specs master: Fix issues for post-allocations spec https://review.openstack.org/509136 | |
| 10:32:07 | cdent | efried: that ^ should fix some of your comments, thanks for them | |
| 10:37:53 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Remove dead code of api.fault notification sending https://review.openstack.org/505164 | |
| 10:45:11 | openstackgerrit | Stephen Finucane proposed openstack/nova master: doc: Add documentation for cpu_realtime, cpu_realtime_mask https://review.openstack.org/502056 | |
| 10:46:21 | stephenfin | gibi, bauzas: Any chance of a (re-)review of ^ | |
| 10:52:36 | openstackgerrit | Chris Dent proposed openstack/nova-specs master: Spec for limiting GET /allocation_candidates https://review.openstack.org/504540 | |
| 10:59:11 | tetsuro | The patch I brought in the latest PTG is ready for review https://review.openstack.org/#/c/465160/. | |
| 10:59:37 | tetsuro | This is a bug that falls into silent error with NUMATopology when virt_type is not set to kvm. | |
| 11:18:09 | gibi | stephenfin: done. +2 | |
| 11:18:44 | gibi | stephenfin: thanks for the respin of the api.fault check. Is there something on master that will help pleasing jenkins? Should I rebase my other patches as well? | |
| 11:18:58 | gibi | s/check/patch.// | |
| 11:54:49 | openstackgerrit | Chris Dent proposed openstack/nova master: Update RT aggregate map less frequently https://review.openstack.org/489633 | |
| 12:40:58 | stephenfin | sahid: Can you reword the comment here? I'm not sure what you mean https://review.openstack.org/#/c/461456/5/nova/virt/hardware.py | |
| 12:45:44 | sahid | stephenfin: yes i will, there are several points on what i'm not agree with that change | |
| 12:46:15 | stephenfin | sahid: Cool, thanks. I don't personally see the downside so there's a chance I'm missing something | |
| 12:49:15 | sahid | well firstable we add new syntax to provide the same fonctionnality, the previous one already brought bugs, adding a new one is not going to help | |
| 12:51:33 | sahid | then with this new syntax, we allow users to specify the set of vCPUs used to apply the mask on where in my sense that shouldn't be allowed, the mask is applied on the set of vCPUs of the guest which Nova do provide | |
| 12:54:03 | stephenfin | Yeah, they do achieve basically the same thing. However, from a usability perspective, I do think this second pattern is more intuitive | |
| 12:54:43 | stephenfin | I mean, if the option was called 'cpu_realtime_excludes' or something, then the current pattern would make sense (and the carat wouldn't be necessary) | |
| 12:55:46 | stephenfin | However, while nova definitely should keep track of total number of CPUs, I don't see why we should allow "explicit exclude-implicit include", but not "explicit include-implicit exclude" | |
| 12:56:36 | stephenfin | "explicit include-explicit exclude" is an odd one, but it's no harm and already works, so if someone's silly enough to do it I don't see why we shouldn't just let them | |
| 12:57:03 | stephenfin | This is a usability improvement and nothing more, IMO | |
| 12:57:31 | sahid | ok that is the subjective point, i can hear it. what about the fact we add more and more code to achieve the same result? | |
| 13:13:20 | mriedem | blarg my nova-specs dashboard doesn't work with new gerrit | |
| 13:14:14 | cdent | mriedem: bauzas had some links earlier today about ways to fix that | |
| 13:14:39 | bauzas | mriedem: yeah, I had to modify my own dashes | |
| 13:14:44 | cdent | mriedem: http://lists.openstack.org/pipermail/openstack-dev/2017-September/122277.html | |
| 13:14:59 | sdague | bauzas / mriedem are you using the ones from upstream? | |
| 13:15:04 | bauzas | mriedem: tl;dr: labeling your votes doesn't work, you need to use another one | |
| 13:15:17 | sdague | I tried to fix everything in that repo | |
| 13:15:25 | sdague | but, I'm sure they could use tweaks | |
| 13:15:33 | stephenfin | Yeah, https://github.com/openstack/gerrit-dash-creator/blob/master/dashboards/nova-specs.dash looks good to me | |
| 13:15:45 | stephenfin | and I'm using https://github.com/openstack/gerrit-dash-creator/blob/master/dashboards/nova.dash daily | |
| 13:15:59 | bauzas | sdague: I'm using the same queries than yours, but I use https://review.openstack.org/#/settings/preferences | |
| 13:16:10 | sdague | bauzas: ok, cool | |
| 13:16:31 | sdague | bauzas: yeh, I end up just using browser bookmarks for them as they sync between chrome | |
| 13:16:34 | bauzas | sdague: so, tbh I modified my queries thanks to you :) | |
| 13:17:03 | bauzas | that, plus Zuul v3 \o/ | |
| 13:17:12 | bauzas | https://docs.openstack.org/infra/manual/zuulv3.html | |
| 13:17:58 | bauzas | is anyone currently working on moving our jobs to the nova repo btw. ? | |
| 13:18:12 | bauzas | sdague: do you know that ^ ? | |
| 13:19:04 | jaypipes | sdague, mriedem: is it worth rechecking anything at the moment? | |
| 13:19:26 | sdague | jaypipes: I don't know, I rechecked a few things, I'll let you know if anything works | |
| 13:19:32 | jaypipes | kk | |
| 13:19:48 | mriedem | jaypipes: don't think so | |
| 13:19:54 | sdague | bauzas: no, but given that zuul v3 is still not passing many things, it didn't seem really useful to change the queries yet | |
| 13:19:54 | jaypipes | sdague: seeing a lot of POST_FAILURE stuff right now... | |
| 13:19:56 | mriedem | what i have rechecked is not queueing up | |
| 13:20:11 | sdague | jaypipes: yeh... that's what I saw from stuff that hit lastnight | |
| 13:20:36 | jaypipes | mordred: any particular activity that would be useful from us in identifying issues with Zuulv3? | |
| 13:20:39 | bauzas | sdague: well, you're right | |
| 13:20:53 | bauzas | jaypipes: there is an etherpad | |
| 13:21:04 | bauzas | jaypipes: https://etherpad.openstack.org/p/zuulv3-migration-faq | |
| 13:21:08 | jaypipes | bauzas: cheers | |
| 13:21:54 | sdague | mriedem: you want me to restrict down the specs dashboard to only stuff proposed for queens? | |
| 13:22:26 | bauzas | sdague: it's another dash I guess | |
| 13:22:39 | bauzas | sdague: honestly, I'm directly querying for that | |
| 13:23:17 | mriedem | sdague: no that's fine | |
| 13:25:30 | sdague | https://goo.gl/JxQn1r is an attempt to slice things off | |
| 13:25:52 | sdague | so queens for everything, then a bucket at the bottom for non queens stuff | |
| 13:26:24 | openstackgerrit | John Garbutt proposed openstack/nova master: Re-use existing ComputeNode on ironic rebalance https://review.openstack.org/508555 | |
| 13:28:23 | openstackgerrit | Lee Yarwood proposed openstack/nova-specs master: Libvirt: Native LUKS decryption by QEMU https://review.openstack.org/490824 | |
| 13:37:41 | jaypipes | cdent: there isn't a call to get the aggregates for >1 resource provider is there? | |
| 13:38:04 | jaypipes | cdent: nm, no there isn't... | |
| 13:38:42 | cdent | jaypipes: I believe you are correct | |
| 13:38:52 | jaypipes | cdent: was thinking if there was, we could further simplify your agg perf patch to do a single batch call. | |
| 13:38:58 | jaypipes | cdent: but meh, no worries :) | |
| 13:40:09 | cdent | I had a version which was more brute force (but as a result required multiple requests) and decided that was not the way to go. | |
| 13:40:30 | jaypipes | cdent: no, this looks quite good. ++ | |
| 13:41:48 | jaypipes | mriedem, dansmith: https://review.openstack.org/#/c/489633/ looks like a small, well-scoped patch with a good performance benefit. | |
| 13:42:02 | bauzas | cdent: just a slight concern about possibly overthinking about times with https://review.openstack.org/#/c/496853/3 | |
| 13:42:52 | cdent | bauzas: your etag fear has been noted on your api merit badge worksheet as a demerit | |
| 13:43:37 | bauzas | hah | |
| 13:43:44 | jaypipes | lol | |
| 13:44:08 | bauzas | honestly, I just want to make sure we have a very small implementation for that | |
| 13:44:10 | cdent | bauzas: on the last-modified time: since the time info is already there, seems like we may as well use it, because the spec says we should (if possible) include the _real_ time of update | |
| 13:44:20 | bauzas | sure, I understand that | |
| 13:44:32 | bauzas | but IMHO, keeping it simple for Queens isn't bad | |
| 13:44:42 | cdent | since we dismissed etags as part of placement long ago, I think we should stick with that plan, I only include the option to be complete | |
| 13:44:44 | bauzas | unless you really wanna cache | |
| 13:44:56 | bauzas | and then, we should possibly use etags | |
| 13:45:19 | bauzas | so, my thoughts are : do the very small change and just use the current time, or use Etags :p | |
| 13:45:50 | cdent | I think the last-modified time is useful metadata for generic users of the placement service, maybe not in nova-scheduler, but for random unknowns. And since I’ve alrady got a working implementation, it’s not too much effort to finish it | |
| 13:46:22 | bauzas | cdent: well, it needs then to leak out the DB details to the object | |
| 13:46:32 | bauzas | we do that for a lot of stuff of course | |
| 13:46:35 | cdent | one sec | |
| 13:46:51 | bauzas | but I thought our placement objects shouldn't be using that | |
| 13:47:03 | bauzas | anyway, I don't want to nitpick over it | |
| 13:47:04 | cdent | bauzas: this is the wip, is not hard: https://review.openstack.org/#/c/495380/7/nova/objects/resource_provider.py | |
| 13:47:16 | cdent | we alraedy have those fields | |
| 13:47:20 | bauzas | yeah I know | |
| 13:47:27 | bauzas | using a mixin isn't hard | |
| 13:47:44 | bauzas | it's just we're exposing those DB details out to the API | |
| 13:48:15 | bauzas | cdent: is it the first OpenStack project doing that ? (please use your API SIG hat :p ) | |
| 13:48:57 | cdent | I don’t understand what you mean by “exposing those db details out the to the api”. You mean last modified time? Why is that a problem? | |
| 13:49:06 | sdague | mriedem: ok, I'm really struggling about why on - https://review.openstack.org/#/c/501017/2/specs/queens/approved/flavor-description.rst | |