| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-03 | |||
| 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 | |
| 13:51:15 | bauzas | because we could implement preferred= later | |
| 13:51:18 | jaypipes | understood. | |
| 13:51:27 | dansmith | bauzas: exactly | |
| 13:51:31 | stephenfin | ahhh | |
| 13:51:46 | edleafe | preferred won't be in placement, right? | |
| 13:51:52 | edleafe | that's a weigher issue | |
| 13:51:55 | openstackgerrit | John Garbutt proposed openstack/nova master: Re-use existing ComputeNode on ironic rebalance https://review.openstack.org/508555 | |