| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-03 | |||
| 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 | |
| 13:49:15 | sdague | because that's really already there with flavor name | |
| 13:49:42 | jaypipes | edleafe, bauzas, cdent, stephenfin, dansmith, mriedem: I think the only thing remaining on https://review.openstack.org/#/c/497713/10/specs/queens/approved/add-trait-support-in-allocation-candidates.rst is to agree on the name of the parameter. The options are traits=, required=, required_traits=. Let's just pick one. Please #vote for your first and second pick. I'll go first. | |
| 13:50:01 | bauzas | I need to review that spec | |
| 13:50:01 | jaypipes | #vote 1. required=, 2. traits= | |
| 13:50:13 | dansmith | #vote 1. required 2. required= 3. requires= | |
| 13:50:19 | jaypipes | lol | |
| 13:50:25 | dansmith | jaypipes: I thought everyone was okay with required=? | |
| 13:50:40 | jaypipes | dansmith: I don't believe mriedem was and I know edleafe wasn't. | |
| 13:50:42 | edleafe | required= or traits= are fine with me | |
| 13:50:50 | dansmith | edleafe: said he was | |
| 13:50:51 | cdent | bauzas In my limited review of openstack apis, there’s a mix of who does and does not use last-modifed. If we’re looking to limit the amount of work in Queens, we could choose not to do this spec, it isn’t really required in any way. | |
| 13:50:52 | edleafe | requires= is definitely not | |
| 13:50:54 | jaypipes | or was it requires=... | |
| 13:50:55 | bauzas | required= for me | |
| 13:50:56 | jaypipes | yeah, sorry | |
| 13:51:05 | stephenfin | #vote 1. traits=, 2. required= | |
| 13:51:06 | cdent | mriedem expresed dislike for required, yes? | |
| 13:51:08 | dansmith | jaypipes: I think mriedem said required= was okay too | |
| 13:51:13 | edleafe | verbs don't work | |