Thursday, 2018-07-12

corvuslogan-: ++00:30
*** jiapei has joined #zuul01:34
*** dtruong2_ has joined #zuul03:24
*** spsurya_ has joined #zuul03:32
openstackgerritTristan Cacqueray proposed openstack-infra/zuul master: gerrit: rstrip baseurl trailing /  https://review.openstack.org/58194503:56
openstackgerritTristan Cacqueray proposed openstack-infra/zuul master: gerrit: rstrip baseurl trailing /  https://review.openstack.org/58194504:25
logan-thanks tristanC04:26
tristanClogan-: you're welcome, thanks for the report :-)04:28
*** bhavik1 has joined #zuul05:20
*** bhavik1 has quit IRC05:56
*** dtruong2_ has quit IRC05:57
*** nchakrab has joined #zuul06:07
*** gtema has joined #zuul07:15
*** adam_g has quit IRC07:53
*** adam_g has joined #zuul07:54
*** sshnaidm|off has quit IRC08:27
*** hashar has joined #zuul08:29
*** bhavik1 has joined #zuul08:37
*** bhavik1 has quit IRC08:41
*** electrofelix has joined #zuul08:46
*** sshnaidm has joined #zuul08:48
*** sshnaidm is now known as sshnaidm|rover08:48
*** sambetts|afk is now known as sambetts08:57
tobiashShrews: I think we might have some problem in the static driver09:17
tobiashShrews: I'm debugging an issue where I have a node request for a static node, there is a zNode in state ready but it still doesn't get this node09:17
tobiashShrews: the request is in state requested and I see the following regularly in the logs: http://paste.openstack.org/show/725669/09:18
tobiashShrews: then the handler pauses and when it unpauses it does the same again09:20
*** jiapei has quit IRC09:34
odyssey4mehi folks, can I get some reviews for https://review.openstack.org/581348 - while it may be less than perfect, at least it's an improvement to help new developers... the current docs are quite broken09:53
odyssey4mealso, tobiash do you think I should apply https://review.openstack.org/580728 to https://review.openstack.org/581329 given that I've left part of that in the test addition09:54
odyssey4meI could also merge https://review.openstack.org/580728 into https://review.openstack.org/581329 if you like09:55
tobiashodyssey4me: do they conflict?10:18
odyssey4methey do not, however if I do the patch then it'll be easier to get two cores to approve ;)10:18
tobiashodyssey4me: are you sure you mean https://review.openstack.org/580728 ?10:20
tobiashthat doesn't look related10:20
odyssey4metobiash: this is the part I mean: https://review.openstack.org/#/c/580728/1/nodepool/tests/test_launcher.py10:20
odyssey4meie, the clean-up10:20
odyssey4mein my patch I did leave the 'finished waiting' debug line, so I can clean that up if you like10:21
tobiashodyssey4me: I don't see that line in your new test so I think it's fine as is10:23
odyssey4meoh, heh, I cleaned it out yesterday10:23
odyssey4menvm, nothing to see here :p10:23
tobiash580728 is just a trivial stylistic cleanup that can be drive-by approved by any zuul-core10:25
tobiashmordred: wanna do a quick review? ^10:25
tobiashShrews: I think I understood my nodepool issue. I have a static provider with a pool containing multiple static nodes of different labels10:27
tobiashShrews: so now I get a request for label A which is fulfilled, after that I get another request for label A which gets pending and pauses the handler because I only have one node of label A10:28
tobiashShrews: after that I get a third request but now for label B which is free but not serviced because there is a common handler for the pool that is blocked until the second A request can be fulfilled10:29
tobiashShrews: I can do a workaround by having only one label per pool but I think we should make it possible to handle this within the same pool10:30
tobiashShrews: otherwise at some point I'll have 50 or more pools that each declines almost every node request which will just create synchronization contention and reduce reaction times of the whole system10:31
tobiashs/reduce/increase10:31
openstackgerritRoman Gorshunov proposed openstack-infra/zuul master: Fix: correct path to the project's public key  https://review.openstack.org/58214310:54
*** hashar is now known as hasharAway11:21
*** hasharAway has quit IRC11:27
openstackgerritRoman Gorshunov proposed openstack-infra/zuul master: Fix: correct path to the project's public key  https://review.openstack.org/58214311:29
openstackgerritRoman Gorshunov proposed openstack-infra/zuul master: Fix: correct path to the project's public key  https://review.openstack.org/58214311:41
Shrewstobiash: so sounds to me that nodepoool is working as designed, but the request handling is suboptimal given the nature of the static driver12:03
Shrewstobiash: sounds like a different request handling mechanism is needed, but that's a larger change12:04
Shrewstobiash: i've seen other requests for modifying that algorithm, but i think any change to it for something more complex is going to require coordination between the launchers12:05
Shrewsand i don't think we're ready to tackle that yet12:05
tobiashhtm, that will create a problem for me in the long run :/12:09
tobiashok, I'll create a pool per label for now12:10
*** nchakrab_ has joined #zuul12:30
*** nchakrab has quit IRC12:33
odyssey4meShrews: if you could put https://review.openstack.org/581329 into your review queue we'd certainly appreciate it, thanks again for all the help getting those tests started12:34
*** rlandy has joined #zuul12:38
*** bhavik1 has joined #zuul12:50
openstackgerritMerged openstack-infra/nodepool master: Cleanup test_over_quota  https://review.openstack.org/58072812:51
*** bhavik1 has quit IRC13:10
*** dkranz has quit IRC13:11
*** nchakrab_ has quit IRC13:15
*** nchakrab has joined #zuul13:16
*** nchakrab has quit IRC13:37
*** nchakrab has joined #zuul13:38
*** pwhalen has quit IRC13:41
*** nchakrab has quit IRC13:43
*** pwhalen has joined #zuul13:45
*** pwhalen has joined #zuul13:45
openstackgerritJoshua Hesketh proposed openstack-infra/zuul master: Remove redhat-rpm-config bindep  https://review.openstack.org/58125213:52
openstackgerritJoshua Hesketh proposed openstack-infra/zuul master: Fix github setup in zuul from scratch  https://review.openstack.org/58125313:52
openstackgerritJoshua Hesketh proposed openstack-infra/zuul master: fix zuul from scratch user and group creation  https://review.openstack.org/58125413:52
openstackgerritJoshua Hesketh proposed openstack-infra/zuul master: Add instructions for deploying zuul with openSUSE  https://review.openstack.org/58125513:52
openstackgerritJoshua Hesketh proposed openstack-infra/zuul master: Add instructions on building static web components  https://review.openstack.org/58125613:52
*** hwoarang has quit IRC14:12
*** dkranz has joined #zuul14:13
*** nchakrab has joined #zuul14:16
*** nchakrab_ has joined #zuul14:22
mordredtobiash: do you have a list of the alpine packages needed to install zuul you could share?14:23
*** nchakrab has quit IRC14:26
tobiashmordred: http://paste.openstack.org/show/725719/14:32
mordredtobiash: thanks!14:32
tobiashmordred: but that was a growing list which is not necessary minimal today14:33
tobiashmordred: executor additionally needs 'bubblewrap'14:33
*** GonZo2000 has joined #zuul14:34
*** GonZo2000 has quit IRC14:34
*** GonZo2000 has joined #zuul14:34
tobiashmordred: but I'd recommend ubuntu (probably bionic) so wheels from pypi can be used14:35
openstackgerritFabien Boucher proposed openstack-infra/zuul master: zuul-web: jobs list endpoint: return 404 when tenant not found  https://review.openstack.org/58220014:36
*** mugsie has quit IRC14:36
*** mugsie has joined #zuul14:36
*** mugsie has quit IRC14:36
*** mugsie has joined #zuul14:36
corvustobiash, Shrews: the only quick fix i can think of would be to have the static handler never pause, however, that might generate *a lot* of zk traffic.  a second option i thought about would be to internally make separate pool workers per-label (so automate what tobiash is doing), but support for multiple labels makes that complicated.14:37
tobiashcorvus: if the static handler never pauses would it grab another request then?14:39
tobiashcorvus: we could add a backoff to reduce the zk traffic14:40
Shrewscorvus: pausing is not controlled by the driver. we'd have to come up with a mechanism to do that14:40
rcarrillocruzi remember there was at some point a story for 'trigger zuul on $package update URL'14:40
corvusShrews: i know, but it would be a one-liner to change that14:40
corvusShrews: basically change 'self.paused = True' to 'self.setPaused(True)' and then make setPaused a noop in static14:43
corvusthen we can keep using the runHandler method14:43
corvusmind you, i'm not ready to say that's a *good* idea, just an idea.  :)14:43
*** nchakrab_ has quit IRC14:44
corvustobiash: yeah, if there are no 'paused' handlers in a pool worker, it continues handling new requests14:44
mordredtobiash: I have trickier ways so I don't need to reuse those wheels - will show you something soon14:44
tobiashcorvus: I think if we would do that we'd need some backoff mechanism (per request?)14:45
corvustobiash: yeah, that's sort of the missing piece -- how to avoid piling up a bunch of active requests, each of which does a full query of all the zk nodes every few seconds?  the rest of the framework isn't really designed for that.  that's what paused is for.14:47
corvusShrews: currently, if a request is paused, we just keep trying that one request each time through the poolworker loop, right?14:50
Shrewscorvus: correct14:50
corvusthere's no poolworker sleep, right?14:52
corvusso in that situation, we basically just have one thread reading zk nodes continually?14:52
Shrewsi don't think so. i'd have to look at the code again14:52
corvusconsidering that, we may actually not generate any more traffic this way14:53
corvusinstead of one handler reading all the nodes over and over, we'd have N handlers reading all the nodes in sequence14:53
Shrewsevery pool worker reads all requests every 10s, unless there is a paused handler14:56
corvusoh i missed the 10s sleep14:57
tobiashjust wanted to say that it retries every 10s according to the logs ;)14:58
corvusthere's still a bunch of details that would need to be worked out.  there's currently no way to resume a request in progress other than if it's paused, and i don't think we'd want to have more than one request for a label active at a time.  so, in the end, even this 'quick' fix may be a substantial change that needs to be thought through.14:59
tobiashI think we should at least document the current behavior and the workaround15:00
corvusit may be better to rethink the algorithm for static nodes from scratch, then see if there's a way to support that.15:00
corvustobiash: yes15:00
*** hashar has joined #zuul15:00
tobiashso I'm ok for now with the workaround given that I need to do further for us more important optimizations in zuul as we're now at a point where users are complaining about stalls, node failures, ...15:02
tobiashbut it's just many users find many bugs...15:03
tobiashso I'm much of my time in fire fighting mode atm15:04
openstackgerritFabien Boucher proposed openstack-infra/zuul master: zuul-web: jobs list endpoint: Add test and fix tenant not found 500 error  https://review.openstack.org/58181015:06
openstackgerritMonty Taylor proposed openstack-infra/zuul master: Build container images using pbrx  https://review.openstack.org/58016015:20
openstackgerritMonty Taylor proposed openstack-infra/zuul master: Add alpine packages to bindep.txt  https://review.openstack.org/58227615:20
openstackgerritMonty Taylor proposed openstack-infra/zuul master: Move the database libraries to requirements  https://review.openstack.org/58227715:20
openstackgerritFabien Boucher proposed openstack-infra/zuul master: zuul-web: config_errors endpoint: return 404 when tenant not found  https://review.openstack.org/58228115:34
*** hashar has quit IRC15:39
pabelangerQuestion around 3pci jobs, in the case of a downstream zuul (rdoproject) loading a job from upstream (openstack.org), if downstream only wanted to run jobs on master branch (devstack) and not stable branches, would it make sense to express some how in tenant configuration to only include the job@master and ignore all other branches? We had an issue where zuul properly loaded the master, because we fixed it in15:55
pabelangerhttps://review.openstack.org/581441 but I didn't backport properly.  I think we should fix it for devstack, but does raise the question of loading job per branch15:55
corvuspabelanger: i'm confused -- why don't you just specify on the project where you're running the job to only run it on master?15:58
corvusmordred: looking at 582277 -- that one feels a little weird.  we have, at the request of some of our users, tried to keep the requirements file to the minimum requirements.  could we perhaps use [extras] in the requirements files to tell pbrx to add that in when making an image, but it isn't required for everyone?16:03
pabelangercorvus: I believe I did, maybe did it wrong. But I think the traceback from zuul is happening much early then that, we see a traceback when zuul scheduler does a reconfiguration, when it tries to load configs from stable branches, it fails due to syntax issues16:03
pabelangerlet me get traceback16:03
mordredcorvus: yeah - we could do that - I agree, it feels weird16:04
pabelangerhttps://tree.taiga.io/project/morucci-software-factory/issue/1495 sorry, it isn't the best format, but comment 1 from tristanC shows the error16:04
*** nchakrab has joined #zuul16:05
corvuspabelanger: oh, i see.  yeah, i think that mostly should be fixed in devstack.  now, we also have talked about listing specific branches in the main.yaml file, but i don't think i would recommend using that as a solution in this case even if it had been implemented.16:06
corvuspabelanger: to be clear, i understand the issue from the text you wrote here.  that link did not help.  :(16:06
clarkbnot in a great place to dig in right now but one thing I have noticed with third party check is that kata-containers/proxy "changes"/PRs take a long time to queue in the zuul status16:07
clarkbprobably something we need to look into for better user communication16:07
clarkband now meetings16:07
pabelangercorvus: okay, thanks. Yes, that is what I was trying to ask, some list of branches in main.yaml. And agree fixing in devstack is best case here but wanted to raise the question16:08
corvuspabelanger, mordred: have time to chat about pabelanger's issues so far with third party ci?16:13
pabelangerI do yes16:13
*** hwoarang has joined #zuul16:17
*** hwoarang has quit IRC16:17
*** hwoarang has joined #zuul16:17
*** hwoarang has quit IRC16:18
*** nchakrab has quit IRC16:22
mordredcorvus, pabelanger: yes - was just finishing up a chat with notmyname16:22
corvuspabelanger, mordred: cool -- want to use the pbx server and chat on the phone?16:25
pabelangersure, let me see if I have my headphones16:25
*** spsurya_ has quit IRC16:26
mordredcorvus: yah - gimme just a sec and I can join up16:27
pabelangerI do, which room. will join in a minute16:27
corvushow about 600016:28
corvushttps://wiki.openstack.org/wiki/Infrastructure/Conferencing16:28
corvusother folks are welcome to join, but also we can take notes in https://etherpad.openstack.org/p/7X6jiX8fTE and produce a summary of conclusions16:29
*** nchakrab has joined #zuul16:31
corvuspostponed ~3 hours16:39
pabelanger+116:40
*** acozine1 has joined #zuul16:41
*** gtema has quit IRC16:58
*** GonZo2000 has quit IRC17:02
*** sambetts is now known as sambetts|afk17:03
jlkI know y'all don't use GitHub directly, but this could be useful https://blog.github.com/2018-07-12-security-vulnerability-alerts-for-python/17:08
jlkhttps://github.com/openstack-infra/zuul/network/dependencies17:10
jlkhrm, looks like it hasn't picked up requirements.txt yet17:11
*** sshnaidm|rover is now known as sshnaidm|afk17:31
*** nchakrab has quit IRC17:34
*** sshnaidm|afk has quit IRC17:36
*** electrofelix has quit IRC17:42
openstackgerritFabien Boucher proposed openstack-infra/zuul master: Add tenant yaml validation option to zuul client  https://review.openstack.org/57426517:52
openstackgerritJames E. Blair proposed openstack-infra/zuul master: Fix broken templates for projects in dependent pipelines  https://review.openstack.org/58188818:01
corvusfbo: ^ that may be of interest to you18:01
openstackgerritFabien Boucher proposed openstack-infra/zuul master: client: show subcommand propose a more meaningful help message  https://review.openstack.org/58232118:05
openstackgerritJames E. Blair proposed openstack-infra/zuul master: Stop publishing docs to docs.openstack.org  https://review.openstack.org/58232318:10
openstackgerritJames E. Blair proposed openstack-infra/nodepool master: Stop publishing docs to docs.openstack.org  https://review.openstack.org/58232518:11
openstackgerritJames E. Blair proposed openstack-infra/zuul-sphinx master: Stop publishing to docs.openstack.org  https://review.openstack.org/58232618:12
*** harlowja has joined #zuul18:24
*** hwoarang has joined #zuul18:58
*** hwoarang has quit IRC18:58
*** hwoarang has joined #zuul18:58
*** acozine1 has quit IRC19:01
*** dkranz has quit IRC19:02
*** dkranz has joined #zuul19:18
corvuspabelanger, mordred: i'm back from lunch whenever you're ready19:36
pabelangercorvus: yes, 5mins please19:40
pabelangerokay, joining again now19:44
pabelangercorvus: mordred: connected to 6000@pbx.openstack.org19:45
*** acozine1 has joined #zuul20:09
*** dkranz has quit IRC20:38
openstackgerritMonty Taylor proposed openstack-infra/zuul master: Build container images using pbrx  https://review.openstack.org/58016020:57
openstackgerritMonty Taylor proposed openstack-infra/zuul-jobs master: Add role for installing docker and configuring registry mirror  https://review.openstack.org/58073021:04
openstackgerritMonty Taylor proposed openstack-infra/zuul master: Build container images using pbrx  https://review.openstack.org/58016021:09
mordredcorvus, pabelanger: that ^^ is worth reviewing/re-reviewing now21:09
mordredpabelanger: I updated the zuul-jobs role one more time with a line that had been in the job definition in the zuul repo but really belonged in the install-docker role21:09
corvusmordred: oh that's nice and fairly intuitive.  it might be good to put a comment in zuul's setup.cfg stating that though, so people know what those keywords mean21:14
corvusmordred: can extras go in requirements.txt instead of setup.cfg?21:15
corvusapparently so?  https://www.python.org/dev/peps/pep-0508/#extras21:17
mordredcorvus: that's how you indicate consuming them21:18
mordredcorvus: so no, for us to declare an extra, we have to put it in setup.cfg21:19
corvusthat's a really confusing bit of documentation21:20
corvusapparently "when the extra is used in a dependency specification" doesn't mean what i thought it did.21:21
corvusyep.  confirmed.  i'm wrong for wanting wrong things: https://github.com/pypa/pip/issues/116121:22
corvusapparently we should not be using requirements.txt21:22
openstackgerritMonty Taylor proposed openstack-infra/zuul master: Specify a prefix for building the images  https://review.openstack.org/58239621:22
mordredcorvus: yah. we're wrong to want to express dependencies21:22
mordredcorvus: if you express specific dependencies, then you make it harder for a developer who wants to install your software with a different set of dependencies to get that done21:23
mordredcorvus: so explicitly listing your actual dependncies is wrong think21:23
mordredalso, listing them declaratively in requirements.txt is wrong thing - if you list them at all, they should be listed inside of a python executable file as a list argument to a key of a dict, and they should not specify versions21:24
corvusi am learing so much about how to be a better programmer21:25
mordredcorvus: apparently delivering web apps and vendoring your depends is the ultimate in good programming and you should do more of it21:25
*** dkranz has joined #zuul21:38
Shrewscorvus: do you want an opportunity to review https://review.openstack.org/581329 ?21:47
corvusShrews: yep, will do, thanks21:48
*** rlandy is now known as rlandy|afk21:55
corvustristanC, tobiash: https://review.openstack.org/581553 approved with comment21:55
*** sshnaidm|afk has joined #zuul21:57
corvustristanC: https://review.openstack.org/581793 approved with comment22:00
openstackgerritMerged openstack-infra/nodepool master: Add ability to ignore provider quota for a pool  https://review.openstack.org/58132922:03
odyssey4mew00t! thanks tobiash corvus Shrews :)22:05
corvusodyssey4me: thank you :)22:06
* mordred hands odyssey4me what he thinks is probably still mostly a bunny22:08
* odyssey4me considers the existential crisis of what is mostly a bunny, while sipping a perfectly good beverage.22:09
odyssey4meok folks, I'm out for the night - cheerio!22:12
* mordred panics, realizing he is NOT sipping a perfectly good beverage22:12
mordredhave a good one odyssey4me !22:12
openstackgerritMerged openstack-infra/zuul master: timer: skip projects not using the pipeline  https://review.openstack.org/58155322:20
openstackgerritMonty Taylor proposed openstack-infra/zuul master: Build container images using pbrx  https://review.openstack.org/58016022:33
openstackgerritMonty Taylor proposed openstack-infra/zuul master: Specify a prefix for building the images  https://review.openstack.org/58239622:33
openstackgerritMerged openstack-infra/zuul master: zuul-web: key endpoint: return 404 when tenant or project not found  https://review.openstack.org/58179322:36
*** acozine1 has quit IRC22:38
*** rlandy|afk is now known as rlandy23:18
openstackgerritMonty Taylor proposed openstack-infra/zuul master: Build container images using pbrx  https://review.openstack.org/58016023:36
openstackgerritMonty Taylor proposed openstack-infra/zuul master: Specify a prefix for building the images  https://review.openstack.org/58239623:36

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!