| *** zigo has quit IRC | 00:05 | |
| pabelanger | in nodepool, I am not sure how best to accomplish the following. Say I have 1st pool called 4core with max-server: 2 but and 2nd pool is 1core with max-server: 8. I don't want to launch 10 max-servers, because quota will only support a totally of 8 cores. If I set the quota on cloud side, I think I'll be fine since nodepool knows there is only 8cores from openstack, but guess I cannot cap it in nodepool.yaml | 00:08 |
|---|---|---|
| pabelanger | if quota is unlimited | 00:08 |
| pabelanger | I hope that made sense | 00:09 |
| clarkb | pabelanger: correct | 00:14 |
| *** annabelleB has joined #zuul | 00:21 | |
| pabelanger | clarkb: thanks, that's what I figured. | 00:23 |
| clarkb | nodepool relies on the quota info to figure out how much room it has in the mixed lable cases | 00:25 |
| clarkb | s/lable/flavor/ | 00:25 |
| pabelanger | yah, I'll know more tomorrow. Going to try mixed flavors with vexxhost, eg: 1G / 1C for linter jobs | 00:26 |
| *** annabelleB has quit IRC | 00:42 | |
| *** hashar has joined #zuul | 05:41 | |
| *** pcaruana has joined #zuul | 05:41 | |
| *** chkumar|off is now known as chkumar|ruck | 05:42 | |
| *** quique|rover|off is now known as quiquell|rover | 05:45 | |
| openstackgerrit | Merged openstack-infra/zuul-jobs master: Block twine 1.12.0 when we install it https://review.openstack.org/604862 | 06:05 |
| openstackgerrit | Markus Hosch proposed openstack-infra/zuul master: Add support for authentication/STARTTLS to SMTP https://review.openstack.org/603833 | 06:48 |
| openstackgerrit | Ian Wienand proposed openstack-infra/zuul-sphinx master: Add attr_overview directive https://review.openstack.org/604980 | 06:49 |
| ianw | corvus: ^ ok ... there's my attempt; i think it will be useful on the big config pages like nodepool | 06:50 |
| openstackgerrit | Ian Wienand proposed openstack-infra/nodepool master: Add overview of config options https://review.openstack.org/604984 | 07:01 |
| *** quiquell|rover is now known as quique|rover|brb | 07:10 | |
| quique|rover|brb | ianw, pabelanger: Do you know if zuuls build API have argument to get buils since a date ? | 07:14 |
| ianw | tristanC: ^ ? i usually just use the build info page :) | 07:26 |
| ianw | #status log graphite.o.o removed, puppet has run and config file looks ok | 07:32 |
| openstackstatus | ianw: finished logging | 07:32 |
| *** quique|rover|brb is now known as quiquell|rover | 07:42 | |
| *** jpena|off is now known as jpena | 07:53 | |
| *** bhavikdbavishi has joined #zuul | 08:14 | |
| *** chmouel_ has joined #zuul | 08:23 | |
| *** chmouel_ is now known as chmouel | 08:37 | |
| *** panda|off is now known as panda | 09:01 | |
| *** sshnaidm has joined #zuul | 09:07 | |
| *** bhavikdbavishi1 has joined #zuul | 09:29 | |
| *** sshnaidm is now known as sshnaidm|afk | 09:29 | |
| *** bhavikdbavishi has quit IRC | 09:29 | |
| *** bhavikdbavishi1 is now known as bhavikdbavishi | 09:29 | |
| *** sshnaidm|afk is now known as sshnaidm|off | 09:37 | |
| *** sshnaidm|off has quit IRC | 09:42 | |
| *** bhavikdbavishi has quit IRC | 09:54 | |
| *** electrofelix has joined #zuul | 10:00 | |
| *** bhavikdbavishi has joined #zuul | 10:23 | |
| tobiash | mordred, corvus: we're experiencing random segfaults of ansible-playbook on fedora based nodes (alpine based image) | 11:06 |
| *** pcaruana has quit IRC | 11:15 | |
| *** panda is now known as panda|afk | 11:19 | |
| mordred | tobiash: oh excellent | 11:26 |
| tobiash | now the question is will a kernel upgrade from 4.17 to 4.18 fix it or a switch to ubuntu bionic as base image... | 11:26 |
| tobiash | on centos based nodes there are no segfaults btw | 11:27 |
| mordred | tobiash: the alpine image is running on a fedora host? or it's segfaulting when it's running against a remote fedora host? | 11:27 |
| tobiash | our openshift is running on centos atomic and fedora atomic (mixed nodes currently) | 11:27 |
| mordred | gotcha | 11:27 |
| mordred | tobiash: when we had some pbrx issues week before last that we originally thought were due to alpine releasing a bug but which wound up being a pbrx bug ... it made me wonder if we shouldn't switch to the normal python:minimal debian-based base image | 11:29 |
| tobiash | and the executors running on a fedora hosts produce these segfaults | 11:29 |
| mordred | because alpine is awesome - but it is a bit different with musl-libc and whatnot | 11:29 |
| mordred | tobiash: so I'll be interested to learn if a switch of base image has any impact | 11:30 |
| tobiash | let's see | 11:30 |
| mordred | tobiash: also - on a different topic - your request last week for better parallelism in openstacksdk has actually led to a complete redesign of the parallelism system :) | 11:32 |
| tobiash | interesting :) | 11:32 |
| tobiash | will that be compatible with nodepool? | 11:33 |
| *** jpena is now known as jpena|lunch | 11:38 | |
| *** quiquell|rover is now known as quique|rover|lch | 11:49 | |
| *** hashar is now known as hasharAway | 11:50 | |
| *** bhavikdbavishi1 has joined #zuul | 11:51 | |
| *** bhavikdbavishi has quit IRC | 11:53 | |
| *** bhavikdbavishi1 is now known as bhavikdbavishi | 11:53 | |
| tristanC | quique|rover|lch: ianw: btw, i sugested chkumar|ruck to have a look at adding date filter to the builds API | 12:04 |
| *** bhavikdbavishi has quit IRC | 12:07 | |
| *** AJaeger_ is now known as AJaeger | 12:13 | |
| *** jpena|lunch is now known as jpena | 12:40 | |
| *** panda|afk is now known as panda | 12:49 | |
| *** samccann has joined #zuul | 12:50 | |
| *** ssbarnea has quit IRC | 12:56 | |
| *** ssbarnea has joined #zuul | 13:06 | |
| *** quique|rover|lch is now known as quiquell|rover | 13:09 | |
| quiquell|rover | tristanC: I have resolve it using skip, to go to the past | 13:12 |
| quiquell|rover | tristanC: But would be nice to have a since or the like | 13:12 |
| *** hasharAway has quit IRC | 13:37 | |
| tobiash | mordred: I'm not sure but I think there might be a side effect of the openstacksdk parallelization in nodepool that causes failed requests when doing config reloads in nodepool | 13:41 |
| tobiash | when that is done the manager is stopped, the inflight request fails and nodepool does all remaining retries within a few milliseconds against the old stopped manager | 13:41 |
| tobiash | or maybe it's caused because now it's just fast | 13:45 |
| tobiash | mordred: forget the reference to openstacksdk, I think I just ignored this problem | 13:57 |
| tobiash | I think this is inherent to single cloud use cases where a config reload breaks every inflight node launch and thus fails the request with only one provider | 13:59 |
| openstackgerrit | Tobias Henkel proposed openstack-infra/nodepool master: WIP: Try to fix single cloud config reload https://review.openstack.org/605086 | 14:13 |
| tobiash | mordred, Shrews, corvus: what do you think about this idea to fix the single cloud config reload? ^ | 14:14 |
| tobiash | there is no implementation yet, I just layed out the idea directly in the code | 14:14 |
| Shrews | tobiash: why would we need to detach existing nodes from the request? | 14:20 |
| *** quiquell|rover is now known as quique|rover|off | 14:20 | |
| Shrews | just because the manager was restarted doesn't make those invalid | 14:21 |
| tobiash | Shrews: we don't know which provider would take it on the next try so I think that would be the safest | 14:21 |
| tobiash | in a single cloud usecase this is the same restarted provider, but in a multi cloud usecase we probably don't know | 14:21 |
| Shrews | i don't understand. why would another provider take it? the same provider should simply try another launch | 14:21 |
| Shrews | should be similar to the case above it. abort the node, try another launch | 14:22 |
| tobiash | Shrews: if the config change is to move a label from provider a to provider b then the restarted provider a is not allowed to do a retry | 14:22 |
| tobiash | Shrews: yes, that was my first hunch, but then I thought about ^ | 14:23 |
| tobiash | which complicates that case so I think the best we can safely do is to do a complete rollback of that request and pretend it was never worked on | 14:23 |
| mordred | tobiash: ah- so, the thing I'm working on in sdk should make that problem go away | 14:24 |
| mordred | tobiash: beaus there will be no manager to stop/start | 14:24 |
| Shrews | mordred: well, there are 2 things here. restart during launch, and label change during request handling | 14:25 |
| tobiash | yes, the second cannot be fixed in the sdk | 14:25 |
| Shrews | the last being a *very* edge case, but still possible i suppose | 14:25 |
| mordred | yah | 14:25 |
| Shrews | but if we no longer restart the manager on a config change, we won't be able to identify the 2nd thing | 14:26 |
| Shrews | so that probably needs more thought given mordred's upcoming changes to sdk | 14:26 |
| tobiash | hrm | 14:27 |
| tobiash | I'm not sure I wanted to hear that ;) | 14:27 |
| mordred | tobiash: https://review.openstack.org/604926 <-- not finished - needs testing and whatnot - but that's the idea | 14:27 |
| mordred | also - https://review.openstack.org/604521 adds the ability to configure the concurrency number - instead of it just being 5 :) | 14:28 |
| mordred | so - in the new model, each nodepool thread that is making an api call to the cloud just makes the call itself, but the semaphore in the adapter ensures that we can reduce the concurrency so that it's not just 1000 threads all slamming the cloud at the same time | 14:29 |
| mordred | but no need for a TaskManager thread, or a pool of executor threads | 14:29 |
| tobiash | maybe we can just ignore case two and say if the request is taken by a provider it's immutable to config changes (as it is now) | 14:31 |
| *** dmsimard has quit IRC | 14:31 | |
| tobiash | in this case the new concurrency model would just fix it | 14:32 |
| *** dmsimard has joined #zuul | 14:32 | |
| mordred | yeah - I think that's the easiest thing to reason about | 14:32 |
| tobiash | as a config change cannot really be real time critical this might be just ok | 14:32 |
| *** bhavikdbavishi has joined #zuul | 14:33 | |
| tobiash | mordred: so this is a breaking change in the sdk (as it removes the taskmanager completely)? | 14:34 |
| *** annabelleB has joined #zuul | 14:36 | |
| tobiash | Shrews, mordred: so is it worth to work on 605086 until 604926 is merged and released? | 14:37 |
| mordred | tobiash: technically yes - however I believe that nodepool is the only consumer of the taskmanager interface, so I think as long as we land it carefully (so as not to break ourselves) we should be fine - or at least that's how I'm thinking about it | 14:38 |
| tobiash | ok | 14:39 |
| corvus | so is the idea to let the provider keep handling requests even after it's stopped? (even though there's no taskmanager to stop, there's still the idea of the internal nodepool provider which will have been stopped) | 14:42 |
| corvus | that may cause configuration changes to appear not to take effect immediately | 14:43 |
| tobiash | corvus: yes, the provider would finish all requests it already locked | 14:43 |
| corvus | http://git.zuul-ci.org/cgit/nodepool/tree/nodepool/driver/openstack/provider.py#n62 <-- currently the openstack provider uses the taskmanager to cause requests to abort | 14:44 |
| tobiash | corvus: so the idea in 605086 would also undo the requests, but whith this openstacksdk change that would get difficult | 14:45 |
| corvus | if we wanted to maintain + fix current behavior (where config changes have immediate effect), we could still probably tell openstacksdk to remove the adapter or something and then still implement something like 605086 | 14:45 |
| corvus | or, if we wanted to try the "existing requests use old configuration" approach for a while, i guess we could | 14:46 |
| openstackgerrit | Matthieu Huin proposed openstack-infra/zuul master: Proposed spec: tenant-scoped admin web API https://review.openstack.org/562321 | 14:50 |
| tobiash | are there use cases that require an immediate effect of config changes? | 14:51 |
| tobiash | if yes, it's clear that we need to maintain and fix the current behavior | 14:51 |
| clarkb | probably the biggest thing is max-servers being set to 0 to either accomodate a provider request or prevent nodes from being scheduled in a "broken" region | 14:55 |
| clarkb | unsure if that will take effect immediately or not | 14:55 |
| tobiash | currently it does | 14:55 |
| *** hwoarang has quit IRC | 14:56 | |
| mordred | yah - if we just let things play out rather than doing an immediate stop, it would mean the existing requests would continue (continuing to fail) until they were done and no new ones would be created after the config change, yeah? | 14:56 |
| dmsimard | It'd be great to have a way to disable a provider other than setting max-servers to zero | 14:57 |
| dmsimard | like, I dunno, on the CLI nodepool disable <provider> | 14:58 |
| pabelanger | dmsimard: I think the idea of max-server: 0, along with code review myself. Helps create an audit trail | 15:01 |
| dmsimard | pabelanger: sure, but that's probably not mutually exclusive with a convenient and simple way of doing it | 15:01 |
| pabelanger | dmsimard: agree, that required more things to be in place to accomplish | 15:02 |
| *** hwoarang has joined #zuul | 15:06 | |
| *** hwoarang has quit IRC | 15:17 | |
| *** chkumar|ruck is now known as chkumar|off | 15:17 | |
| *** chmouel has left #zuul | 15:25 | |
| *** hwoarang has joined #zuul | 15:26 | |
| *** hwoarang has quit IRC | 15:36 | |
| *** bbayszczak has joined #zuul | 15:37 | |
| *** che-arne has quit IRC | 15:41 | |
| *** hwoarang has joined #zuul | 15:47 | |
| *** bbayszczak has quit IRC | 15:52 | |
| *** sshnaidm|off has joined #zuul | 16:02 | |
| openstackgerrit | Matthieu Huin proposed openstack-infra/zuul master: web: add tenant and project scoped, JWT-protected actions https://review.openstack.org/576907 | 16:04 |
| *** sshnaidm|off has quit IRC | 16:06 | |
| *** sshnaidm has joined #zuul | 16:06 | |
| *** hwoarang has left #zuul | 16:07 | |
| *** pcaruana has joined #zuul | 16:07 | |
| corvus | mordred: the builds page performs a slow query, probably because it's doing a full table scan to check the tenant (also because there's no limit applied, but that's a separate problem). do you think it will be sufficient to index the tenant column as-is to speed that up? here's the info: http://paste.openstack.org/show/730735/ | 16:25 |
| Shrews | corvus: been a while since my query opt days, but i don't think that will help much | 16:27 |
| Shrews | not enough variation across tenants | 16:27 |
| Shrews | (i'm suspecting... could be wrong since i only just peeked at what you have) | 16:28 |
| Shrews | maybe a zuul_buildset key composed of (buildset_id, tenant) might be more beneficial? | 16:30 |
| corvus | Shrews: yeah, i'm not sure what helps there.... | 16:30 |
| *** annabelleB has quit IRC | 16:36 | |
| tobiash | Maybe the missing limit is the bigger problem | 16:36 |
| mordred | corvus: looking (and reading what Shrews is saying) | 16:37 |
| Shrews | corvus: a key that contains both the join key AND the filter key might work actually | 16:37 |
| mordred | tobiash: limit gets applied after the query - so the initial poor scan still has to happen | 16:38 |
| mordred | corvus: this is the list-of-builds page, yeah? | 16:38 |
| mordred | hrm. | 16:41 |
| mordred | so - yeah, what Shrews said - tenant is going to have super low cardinality so won't be helpful - other than it should be in the index for final filtering | 16:42 |
| mordred | yes - I believe a buildset_id, tenant index will help | 16:43 |
| mordred | or, actually, an index on builds with id, buildset_id, then an index on buildsets on id, tenant - SHOULD maybe getit to do an index scan on builds followed by index lookups for the join and where condition | 16:45 |
| * Shrews hands mordred a box of Sakila memberberries | 16:45 | |
| Shrews | they're either Sakila branded, or Sakila flavored. | 16:47 |
| *** annabelleB has joined #zuul | 16:47 | |
| mordred | mmm. candied dolphin | 16:48 |
| *** panda is now known as panda|off | 16:52 | |
| corvus | Shrews, mordred: i'll grab a local copy of the db and try that. | 17:00 |
| mordred | corvus: I suppose I could also do that too - when you grab a dump, let me know where it is | 17:01 |
| corvus | mordred: zuul01:~root/zuul.sql.gz | 17:02 |
| openstackgerrit | Fabien Boucher proposed openstack-infra/zuul master: WIP - Pagure driver https://review.openstack.org/604404 | 17:03 |
| mordred | corvus: cool, thanks | 17:09 |
| corvus | mordred: also /tmp to make scp easier :) | 17:09 |
| mordred | yay that's better | 17:10 |
| mordred | fbo: you're just having all the fun :) | 17:14 |
| *** jpena is now known as jpena|off | 17:29 | |
| mordred | corvus: those didn't work - I'm trying other more weird things | 17:30 |
| *** panda|off has quit IRC | 17:41 | |
| mordred | corvus: I got it better using 2 subqueries and a manual limit | 17:41 |
| corvus | manual limit? | 17:41 |
| mordred | explain SELECT zuul_buildset.id FROM zuul_buildset INNER JOIN zuul_build ON zuul_buildset.id = zuul_build.buildset_id where zuul_build.id in (select a.id from zuul_build as a where a.id > (select max(b.id) - 1000 from zuul_build as b) ORDER BY a.id DESC); | 17:41 |
| corvus | oh i think i understand manual limit :) | 17:42 |
| mordred | :) | 17:42 |
| mordred | you can't use limits in subqueries ... I can't find a way to get the optimizer to do what we're wanting in a more simpler way yet | 17:42 |
| *** jimi_|ansible has joined #zuul | 17:43 | |
| *** panda has joined #zuul | 17:45 | |
| *** panda is now known as panda|off | 17:47 | |
| *** annabelleB has quit IRC | 17:52 | |
| *** annabelleB has joined #zuul | 17:54 | |
| corvus | mordred: i think i got something close to your original idea to work, but i had to delete the buildset_id index on zuul_build. but maybe we can get it to work by forcing the use of certain indexes? | 17:54 |
| corvus | i'll paste | 17:54 |
| corvus | mordred: http://paste.openstack.org/show/730737/ | 17:56 |
| corvus | mordred: if i understand the explain -- it *only* used the primary keys? | 17:57 |
| corvus | mordred: yeah, if i drop all the new indexes it still does the same thing | 17:59 |
| Shrews | 20 rows? did you delete some data? | 18:00 |
| *** bhavikdbavishi has quit IRC | 18:04 | |
| Shrews | nm. didn't notice the type of "index" there. i guess that's an indication that, yeah, it worked | 18:07 |
| corvus | Shrews: yeah, i guess it's flipped the order -- it's scanning build first instead of buildset | 18:10 |
| corvus | how it can do that and apply the limit given the where clause i dunno -- i guess it can do the join and filter together, up to the limit, then it's done? | 18:11 |
| Shrews | why do i not see a where clause in that paste? | 18:14 |
| corvus | huh i don't know, it's in my history. maybe a mispaste. i'll redo | 18:16 |
| corvus | i guess that's an earlier version i did without the where. with the where it's similar but the row estimates are a bit larger: http://paste.openstack.org/show/730740/ | 18:18 |
| SpamapS | corvus: the trouble with explains in modern mysql is that they *do* consider the size of indexes, so it might actually work differently when there are 20000 rows. | 18:22 |
| SpamapS | FROM zuul_build INNER JOIN zuul_buildset ON zuul_buildset.id = zuul <-- is that just cut off? | 18:23 |
| SpamapS | must be | 18:23 |
| SpamapS | = zuul_build.buildset_id is what I'd expect to see there. | 18:23 |
| SpamapS | I don't see any indexes that would be usable for that join btw | 18:24 |
| SpamapS | hard to know w/o seeing the full WHERE | 18:25 |
| SpamapS | but generally this kind of index isn't as useful as you'd think: KEY `idx_test1` (`id`,`buildset_id`) | 18:25 |
| SpamapS | Because id, the PK, is *already* a component of every index, and having it there may actually prevent the index's usage. | 18:25 |
| SpamapS | I'd suggest adding an index in that is just buildset_id and trying the explain again. | 18:26 |
| * SpamapS goes back to making slides for AnsibleFest | 18:27 | |
| mordred | SpamapS: amusingly enough - there was originally one of those and its presence made mysql do bad things | 18:30 |
| Shrews | i think the obvious solution is to switch to postgres, a real database with transactions | 18:32 |
| * Shrews hides | 18:33 | |
| * mordred throws a Shrews at Shrews | 18:33 | |
| clarkb | why stop there, mssql runs on linux now | 18:33 |
| * clarkb has had his fun for the day now | 18:33 | |
| mordred | corvus: I see you also explored an int tenant id column too | 18:33 |
| corvus | mordred: yeah, it seemed to have no effect | 18:34 |
| corvus | gah yeah the paste is getting cut off | 18:34 |
| corvus | http://paste.openstack.org/show/730741/ | 18:35 |
| corvus | that's reformatted with the complete line | 18:36 |
| corvus | fwiw, with the original schema, this works: FROM zuul_build force index (PRIMARY) INNER JOIN zuul_buildset force index(PRIMARY) ON zuul_buildset.id = zuul_build.buildset_id | 18:37 |
| fungi | anybody have any ideas for zuul-oriented things we would like to bring up for discussion/feedback at the forum in berlin in a couple months? http://lists.zuul-ci.org/pipermail/zuul-discuss/2018-September/000546.html | 18:39 |
| corvus | actually that can be reduced to: FROM zuul_build force index (PRIMARY) INNER JOIN zuul_buildset ON zuul_buildset.id = zuul_build.buildset_id | 18:40 |
| corvus | so basically the buildset index (KEY `buildset_id` (`buildset_id`)) on zuul_build was throwing it off. | 18:41 |
| mordred | yah - I think because it's a smaller index? | 18:41 |
| corvus | tobiash, tristanC, SpamapS, clarkb, pabelanger: ^ see msg from fungi | 18:42 |
| clarkb | corvus: fungi maybe a session on job reusability | 18:43 |
| clarkb | seems like that is consistently somethign we run into corner cases with | 18:43 |
| corvus | yeah, that may be a good idea -- we're still trying to figure out how to do that, and we may have enough non-openstack-upstream users there to talk about it | 18:44 |
| fungi | reusability as in the discussion about openstack's ironic project wanting to provide in-repository parent jobs for its third-party ci ecosystem to derive from? | 18:44 |
| fungi | that could be interesting | 18:44 |
| clarkb | fungi: that, but also constructing zuul-jobs in a way that allows spamaps to use them without importing all of openstack (its actually not zuul-jobs that has that problem) | 18:44 |
| tobiash | corvus, fungi: my collegues are working on something that makes reusability of zuul jobs and roles easier for the user like some kind of market place | 18:45 |
| tobiash | we call that zubbi (zuul building block index) | 18:45 |
| Shrews | lol | 18:45 |
| tobiash | would that be a useful topic there | 18:45 |
| tobiash | ? | 18:45 |
| clarkb | tobiash: ya I think the method of communicating shareable bits is likely also worth discussing in that forum (pun intended) | 18:46 |
| tobiash | (most parts of it will be open source hopefully soon) | 18:46 |
| corvus | yes that sounds like a great thing to talk about | 18:47 |
| clarkb | one of the ideas that came up at the ptg was optional namespacing | 18:48 |
| clarkb | so that you clearly specify when something had to be specific, but otherwise leaving other items globally overrideable | 18:48 |
| corvus | clarkb, tobiash: if you can submit each of those topics via https://www.openstack.org/summit-login/login?BackURL=%2Fsummit%2Fberlin-2018%2Fcall-for-presentations that would probably be best. if needed, we can combine them, or have a double session, etc. | 18:48 |
| clarkb | ok I'll put a submission in after the infra meeting | 18:48 |
| fungi | i also like the name "zubbi" ;) | 18:50 |
| openstackgerrit | Matthieu Huin proposed openstack-infra/zuul master: Proposed spec: tenant-scoped admin web API https://review.openstack.org/562321 | 18:51 |
| fungi | and yeah, i just wanted to remind people about forum submissions since the official deadline for those is at the "end" of tomorrow (not sure what "end" of a day is in that context, though likely no earlier than utc midnight) | 18:51 |
| tobiash | corvus: I'll ask them if that's ok (swest and Felix plan to join the Summit as well) | 18:52 |
| *** gouthamr has quit IRC | 18:52 | |
| *** dmellado has quit IRC | 18:53 | |
| corvus | tobiash, swest: thanks. the forum is for users/ops/devs to get together and discuss things. so it's not a presentation, more of a venue where we can all talk about the need, the development you're doing, and how we can facilitate it or incorporate it. | 18:54 |
| tobiash | zubbi is basically an index of zuul jobs, roles and playbooks and makes it easy to search and view the documentation (using the standardized documentation like in zuul-jobs) without needing to look into various repos | 18:55 |
| tobiash | I think it will be very useful especially for non-day-to-day job authors | 18:56 |
| tobiash | but my collegues can explain that much better as they developed it | 18:56 |
| corvus | tobiash: sounds great! we talked about having some of that in the zuul web ui too, so it'll be good to talk about how they fit together | 18:57 |
| openstackgerrit | Matthieu Huin proposed openstack-infra/zuul master: web: add tenant and project scoped, JWT-protected actions https://review.openstack.org/576907 | 18:59 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul master: Speed up build list query under mysql https://review.openstack.org/605170 | 19:05 |
| *** toabctl has quit IRC | 19:05 | |
| corvus | Shrews, tristanC, mordred, SpamapS: ^ i think that should do it. that should get openstack's build query from 20 seconds down to 0. | 19:06 |
| corvus | (also, it turns out it is including the limit in the query, i just missed it earlier, so that should be fine) | 19:07 |
| *** toabctl has joined #zuul | 19:07 | |
| mordred | corvus: woot! | 19:07 |
| mordred | corvus: +A | 19:07 |
| corvus | sadly that's a scheduler restart so it'll be quite some time before we see if it works | 19:08 |
| pabelanger | Not sure what budget for summit looks like, haven't discussed with new manager yet | 19:11 |
| *** gouthamr has joined #zuul | 19:12 | |
| *** ssbarnea|bkp has quit IRC | 19:14 | |
| *** ssbarnea|bkp has joined #zuul | 19:15 | |
| *** electrofelix has quit IRC | 19:32 | |
| *** jlk has quit IRC | 19:44 | |
| *** jlk has joined #zuul | 19:50 | |
| *** gouthamr_ has joined #zuul | 20:05 | |
| *** dmellado has joined #zuul | 20:07 | |
| SpamapS | mordred: orly? I'd love to see the original explain | 20:17 |
| SpamapS | just for my own curiosity | 20:17 |
| mordred | SpamapS: http://paste.openstack.org/raw/730735/ | 20:18 |
| mordred | SpamapS: but I think you were spot-on about part of it | 20:19 |
| SpamapS | yowza wow that's bad mysql | 20:19 |
| mordred | I thinkn it was ignoring the compound key because it was a larger key, then looking at the buildset_id key, deciding it didn't have enough fields and then just giving up and table scaning | 20:20 |
| mordred | SpamapS: https://review.openstack.org/605170 wound up working | 20:20 |
| *** annabelleB has quit IRC | 20:28 | |
| SpamapS | mordred: I see also now where it might have worked to add that id+buildset_id if you could work it as a range query for the ORDER BY | 20:35 |
| mordred | SpamapS: did you see my fancy double-sub-query version? | 20:36 |
| mordred | (it was not the correct choice) | 20:37 |
| *** gouthamr has quit IRC | 20:38 | |
| *** gouthamr_ is now known as gouthamr | 20:39 | |
| SpamapS | mordred: no, but I also would love to see how a newer mysql handles | 20:40 |
| SpamapS | 5.7 and 8.0 are supposed to have some big leaps in optimizers. | 20:40 |
| *** pcaruana has quit IRC | 20:43 | |
| mordred | SpamapS: oh - I did the same explain in 5.7 and it had the same result :) | 20:46 |
| mordred | SpamapS: mordred | explain SELECT zuul_buildset.id FROM zuul_buildset INNER JOIN zuul_build ON zuul_buildset.id = | 20:46 |
| mordred | | zuul_build.buildset_id where zuul_build.id in (select a.id from zuul_build as a where a.id > (select | 20:46 |
| mordred | | max(b.id) - 1000 from zuul_build as b) ORDER BY a.id DESC); | 20:47 |
| *** annabelleB has joined #zuul | 20:48 | |
| pabelanger | clarkb: thanks to help from mnaser, setting up the quota on nodepool side worked as you said yesterday. Now to keep testing with more flavors | 20:50 |
| pabelanger | it is alittle awkward at first, but we now have centos-7-1vcpu / centos-7-4vcpu nodesets | 20:52 |
| pabelanger | not sure if it would work, or how it would look, but maybe a nodeset could also accept a flavor-id / flavor-name setting. So, a single centos-7 nodeset could use both flavors by default (if not added) or specific if added | 20:54 |
| pabelanger | but for now, using unique labels works | 20:54 |
| *** samccann has quit IRC | 20:58 | |
| openstackgerrit | Ian Wienand proposed openstack-infra/nodepool master: Add overview of config options https://review.openstack.org/604984 | 21:09 |
| ianw | corvus: ^ from prior run (that just fixes a blockquote i didn't want), but i think you're idea of using that object list works out ok to create summaries of attributes -> http://logs.openstack.org/84/604984/1/check/tox-docs/74dabc8/html/configuration.html#configuration | 21:14 |
| corvus | ianw: i wonder how we could get it to match the order... maybe we could make that an ordereddict? | 21:16 |
| corvus | ianw: (i was momentarily confused because 'providers' is at the top of the list, but 'webapp' appears first) | 21:17 |
| ianw | hrm, yeah. i dunno, i'll take a look | 21:18 |
| corvus | ianw: we won't be guaranteed of the order of attributes in different files, but within the same file, i think the order would be preserved, so it should work well enough for this i think | 21:18 |
| ianw | corvus: ahh, i see them ordered locally, and probably that's because i'm building with a later python that has ordered dictionaries by default | 21:23 |
| corvus | ianw: yay the future :) | 21:23 |
| clarkb | was that 3.5 or 3.6? | 21:24 |
| ianw | 3.6 | 21:24 |
| corvus | though it's not clear to me why that used to be insecure but now isn't :) | 21:25 |
| clarkb | I think it had to do with generating collisions. If they've fixed the collision aspect of it then the denial of service concerns go away as do the timing attacks (against lookup times) | 21:27 |
| corvus | ah, since it's a new impl, maybe that's so | 21:27 |
| corvus | looks like the behavior is in 3.6 and guaranteed in 3.7, so effectively 3.6+ | 21:27 |
| corvus | ah, here's original security info: https://mail.python.org/pipermail/python-announce-list/2012-March/009394.html | 21:28 |
| ianw | it's a bit annoying that "basepython=python3" is really a misnomer, because in this and other respects, if you're testing with a version not in production you've got problems | 21:32 |
| openstackgerrit | Ian Wienand proposed openstack-infra/zuul-sphinx master: Add example and type options to attributes https://review.openstack.org/604267 | 21:34 |
| openstackgerrit | Ian Wienand proposed openstack-infra/zuul-sphinx master: Add attr_overview directive https://review.openstack.org/604980 | 21:34 |
| openstackgerrit | Ian Wienand proposed openstack-infra/zuul-sphinx master: Use OrderedDict for object tracking https://review.openstack.org/605240 | 21:34 |
| ianw | corvus: ^ a local build with python3.5 and that gets the ordering right | 21:34 |
| openstackgerrit | Ian Wienand proposed openstack-infra/nodepool master: Add overview of config options https://review.openstack.org/604984 | 21:37 |
| *** dkehn has quit IRC | 21:41 | |
| *** dkehn has joined #zuul | 21:43 | |
| *** jimi_|ansible has quit IRC | 21:47 | |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul master: Web: don't update the status cache more than once https://review.openstack.org/605243 | 21:58 |
| clarkb | how does https://etherpad.openstack.org/p/qyli9cYnhg look for short and to the point forum session proposal | 22:32 |
| * clarkb goes with it under the assumption that it can be edited later (not sure if this assumption is valid) | 22:37 | |
| clarkb | ok submitted with the info on the etherpad. It looks like I can edit it if necesary | 22:42 |
| corvus | tobiash: ^ fyi | 22:52 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!