Monday, 2018-06-18

openstackgerritTristan Cacqueray proposed openstack-infra/zuul master: configloader: skip merger:cat when no items are included  https://review.openstack.org/57601601:42
*** ianychoi_ has joined #zuul02:58
*** ianychoi_ has quit IRC03:01
*** ianychoi has quit IRC03:02
*** ianychoi_ has joined #zuul03:02
*** rlandy has joined #zuul03:08
*** bhavik1 has joined #zuul03:12
*** rlandy has quit IRC03:21
*** bhavik1 has quit IRC03:43
tobiashtristanC: added a question on ^05:15
*** jesusaur has quit IRC05:17
*** swest has quit IRC05:24
*** swest has joined #zuul05:25
tristanCtobiash: thanks, replied with more informations05:26
tristanCtobiash: also, regarding configloader scale issue, I'd like to propose a mechanism to handle project-created event, something that would auto-add new projects to avoid having to reload the scheduler for every project addition05:27
tobiashtristanC: in that case you probably want regex matching of projects in the tenant config?05:28
tristanCtobiash: yes, something along those line would help05:28
tristanCnot sure if github sends such event though05:28
tristanCmaybe we could associate the event to a custom config-reload pipeline, like that we could use "zuul enqueue" to manually inject new projects in zuul05:30
tobiashtristanC: I understand what you're trying to achieve in 576016 but still don't understand that from a data structure point of view as that what you're checking for None should already evaluate to an empty list above05:30
tobiashtristanC: github sends such an event: https://developer.github.com/v3/activity/events/types/#projectevent05:30
tristanCtobiash: a project defined like "- org/project1: { include: [] }" is having all objects in its load_classes05:32
tristanCwe need a special case where user set include to empty list (!= None) to skip load_classes05:32
tristanCthe groups4.yaml test show the issue, without this extra "is None" check, unwanted merger:cat job are used05:34
tobiashtristanC: but then only the None check should be sufficient as in the case 'not project_include' is always true05:35
tobiashthat if statement is pretty confusing05:35
tristanCi agree :-)05:36
tristanCwe just changed our zuul configuration generator, and it's now using per project settings instead of projects groups. Took some time to figure-out why reload took *much* longer...05:37
tristanC(most our projects are -distgit with include:[], no .zuul.yaml support)05:39
tobiashtristanC: it might make sense to change that to if ... is None project_include = current_include else project_include = frozenset( ...05:40
tristanCtobiash: good idea, let's give it a try05:41
tobiashand add a short comment to that explains why we're checking to none instead of empty set here05:41
tobiashI think that could make it cleare05:42
tobiashclearer05:42
openstackgerritTristan Cacqueray proposed openstack-infra/zuul master: configloader: skip merger:cat when no items are included  https://review.openstack.org/57601605:47
*** Rohaan has joined #zuul06:08
Rohaan tristanC: Is there any specific order in which you need to start Zookeeper, nodepool and zuul services? I've been getting /zuul/api/tenant/local/status: Service Unavailable since this morning :( . I'm trying to restart zuul services after oc cluster up like this: https://pastebin.com/dz9sS0Y706:26
tristanCRohaan: zookeeper needs to be restarted first06:27
tristanCRohaan: and since you are re-creating the openshift cluster, i think you can also rm -Rf /var/lib/zookeeper/version-2/*06:28
*** gtema has joined #zuul06:31
*** pcaruana has joined #zuul06:35
*** dmellado has joined #zuul06:41
RohaantristanC: I tried these steps but still I get this error :( Is there something I could be missing? I get EndOfStreamException in zookeeper status logs https://pastebin.com/7Hid2GR5.06:43
*** yolanda__ is now known as yolanda06:43
tristanCRohaan: seems like nodepool (12:04:06 IST; 7min ago) needs to be restarted after zookeper restart (12:07:21 IST; 3min 52s ago)06:45
tristanCRohaan: zookeeper is like the state machine of zuul and nodepool, it needs to be running early on06:46
*** hashar has joined #zuul06:51
RohaantristanC: Does any of these services need to be restarted at all after oc cluster up??06:55
tristanCRohaan: no, nodepool should self-heal when openshift provider is restarted06:56
RohaanHm06:56
tristanCRohaan: but iirc, there are issue when your server restart, nodepool and zuul really needs access to a running zookeeper service06:56
RohaantristanC: Oh I see.06:59
Rohaanlet me wait for some time and see if nodepool makes a connection to zookeeper07:00
*** jesusaur has joined #zuul07:03
tristanCtobiash: before and after the "include: []" (restart at 06:55) fix: https://softwarefactory-project.io/grafana/d/000000001/zuul-status?panelId=44&fullscreen&orgId=1&from=1529304005142&to=1529305862695 :)07:11
tobiash:)07:13
*** jpena|off is now known as jpena07:43
openstackgerritTristan Cacqueray proposed openstack-infra/nodepool master: zk: use kazoo retry facilities  https://review.openstack.org/53553707:51
openstackgerritTristan Cacqueray proposed openstack-infra/nodepool master: zk: retry initial zookeeper connection attempts  https://review.openstack.org/57604707:51
openstackgerritTristan Cacqueray proposed openstack-infra/zuul master: zk: use kazoo retry facilities  https://review.openstack.org/53620907:55
openstackgerritTristan Cacqueray proposed openstack-infra/zuul master: zk: retry initial zookeeper connection attempts  https://review.openstack.org/57604807:55
*** sshnaidm has quit IRC08:09
*** sshnaidm has joined #zuul09:34
*** Rohaan___ has joined #zuul10:23
*** Rohaan has quit IRC10:23
*** Rohaan___ is now known as Rohaan11:05
*** jpena is now known as jpena|lunch11:08
*** Rohaan has quit IRC11:14
*** jpena|lunch is now known as jpena12:03
*** rlandy has joined #zuul12:17
ShrewsA wrist injury from a few years ago is giving me major problems. Headed to the dr today so won't be around much. Very hard to type atm12:37
tobiashShrews: oh, hope it'll get better soon12:49
tobiashcorvus, fungi: during working on that ansible logging problem I totally forgot to send the security notice about the no_log issue13:04
tobiashcorvus, fungi: draft here: https://etherpad.openstack.org/p/rK1f4cRdHq13:05
tobiashdmsimard: ^13:06
fungitobiash: thanks, i noticed we also didn't include a release note about it (at least not that i could find). i might as well go ahead and get a cve issued for it as well13:06
dmsimardtobiash: the scope is a bit larger, sec13:07
dmsimardtobiash: there is a CVE13:07
dmsimardsec13:07
fungii thought the cve was for a defect in ansible, and our devect was similar but not the same? or was the patch to zuul basically identical to the patch for ansible?13:08
tobiashfungi: it basically was as we did the same mistake in the callback as upstream ansible13:08
tobiashs/was as/was the same as/13:09
dmsimardtobiash: which is still vulnerable despite ansible being fixed ?13:10
fungii guess what i'm asking is whether it's identical enough to the defect in ansible that mitre would prefer reusing that cve and updating it in their database vs issuing a new cve for zuul13:10
tobiashdmsimard: I assume so13:11
tobiashactually we had two bugs in there13:11
dmsimardmy understanding is that the defect was in ansible and it was "cascading" down to Zuul (and ARA) as a result but tobiash came up with a zuul fix that I haven't looked at in depth13:11
dmsimardtobiash: ok so I think it's fair to talk about the two seperate ones and how they might be related13:12
dmsimardi.e, in any case operators will want to update to the latest 2.4/2.5 dot releases once they are shipped13:12
dmsimard2.5.5 is already out with the fix since the 14th13:13
dmsimard2.4.5 is in rc113:13
tobiashdmsimard: I'm not sure but we at least had the a check in our callback that was broken in a very similar way than upstream ansible13:14
dmsimard++13:14
tobiashthe second bug was that we didn't handle v2_runner_on_unreachable in the zuul_stream callback13:15
tobiashfungi: should we then get a cve for zuul (given that we didn't do that on the last issues)?13:16
tristanCtobiash: fwiw, anyone can request a cve using this form: https://cveform.mitre.org/13:17
*** elyezer has joined #zuul13:17
tristanCit seems like a good idea considering zuul>=3.0<3.1 is affected13:19
dmsimardtobiash: added some notes on the etherpad13:25
dmsimardtobiash: brb13:25
tobiashdmsimard: cool, thx13:26
*** gtema has quit IRC13:32
fungitobiash: what was the last issue?13:33
tobiashfungi: we basically had the same user visible error in both callbacks (zuul_stream, zuul_json)13:34
fungiif you're referring to the ones we announced before 3.0 was released, then those didn't need a cve. cve is for tracking vulnerabilities in released versions of software and at least as far as i was aware this was the first exploitable vulnerability we had discovered after 3.0.0 was released13:34
tobiashah ok, I think the last one was before the 3.0 release13:34
fungibut entirely possible i missed the discussion around a previous one13:34
corvus"exploitable" is iffy for this one, but if ansible figured it was, no reason to argue.  :)13:37
tobiashcorvus: it even might be exploitable by shutting down the test node during the build13:38
corvustobiash: fair.  etherpad lgtm13:39
fungiyeah, i suppose in this case it's more the risk that you accidentally expose credentials in published logs people could search through13:39
corvusfungi: that's definitely bad, the thing i wasn't clear about was whether you could intentionally trigger it.13:40
fungido we want a patch to add a 3.1.0 release note for this fix too?13:40
corvusfungi: seems reasonable13:41
corvustobiash: if you're ready to send that message, i can approve it now, before i hop on the plane13:42
tobiashcorvus: so send it without a cve?13:42
fungitobiash: did you want me to fill out the cve request form? if so i can do that and then include the cve number in the release note patch13:42
corvusoh, you're waiting on the cve.  nm13:42
fungiyou can always announce without a cve assignment and then i can reply with the cve number. there's really no need to wait for cve assignments to disclose something13:43
corvustobiash: any of the infra-root folks should be able to approve the moderation request in my absence13:43
tobiashfungi: that would be great, thx13:44
tobiashfungi, corvus: so I'll send the mail now and the cve will be part of the release notes patch?13:44
tobiashthat's ok?13:44
fungiyep13:44
corvuswfm13:45
fungibecause i haven't completed my vmt process fork for zuul yet, i'll be following https://security.openstack.org/vmt-process.html#send-cve-request but s/openstack/zuul/ for the "vendor" field13:45
tobiashcorvus: mail sent and safe travels13:47
corvustobiash: approved, thanks!13:49
*** sshnaidm_ has joined #zuul13:54
*** sshnaidm has quit IRC13:57
fungii've gotten confirmation that my cve request was received. hopefully will have an assignment in a few hours, or else they'll tell us to reuse the same cve as ansible14:31
fungieither way, i'll push up a review to add the release note once i get something back from mitre14:31
*** acozine1 has joined #zuul15:00
*** sshnaidm_ has quit IRC15:06
*** dtruong_ has joined #zuul15:07
*** dtruong has quit IRC15:12
*** sshnaidm_ has joined #zuul15:19
*** sshnaidm_ has quit IRC15:48
openstackgerritFabien Boucher proposed openstack-infra/zuul master: Prevent Zuul scheduler to crash at startup if gerrit down  https://review.openstack.org/57619216:00
*** gtema has joined #zuul16:08
*** sshnaidm_ has joined #zuul16:16
*** pcaruana has quit IRC16:20
*** sshnaidm_ is now known as sshnaidm|afk16:20
*** hashar is now known as hasharAway17:05
Shrewstobiash: thx but looking like another surgery might be needed  :(17:05
*** dkranz has quit IRC17:06
*** dkranz has joined #zuul17:08
*** jpena is now known as jpena|off17:15
openstackgerritMonty Taylor proposed openstack-infra/zuul-jobs master: Just use chmod instead of file for log permissions  https://review.openstack.org/57621517:20
*** myoung is now known as myoung|lunch18:08
*** pcaruana has joined #zuul18:25
*** pcaruana has quit IRC18:39
openstackgerritMerged openstack-infra/zuul-jobs master: Just use chmod instead of file for log permissions  https://review.openstack.org/57621518:45
*** sshnaidm|afk has quit IRC18:49
*** gtema has quit IRC18:50
*** myoung|lunch is now known as myoung19:16
*** sshnaidm|afk has joined #zuul19:24
*** acozine1 has quit IRC20:47
openstackgerritMohammed Naser proposed openstack-infra/zuul-jobs master: Add PATH to `ip` command execution  https://review.openstack.org/57627421:37
*** EmilienM is now known as EmilienM_PTO21:45
*** hasharAway has quit IRC22:07
*** myoung is now known as myoung|off22:07

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