[OpenStack-Infra] ERROR gear.Server: Exception in poll loop
Hi Guys,
I hit an error in My CI setup, somehow Gear could not call
Jenkins jobs. zuul could watch gerrit events fine.
And I tried this 'root@r52:~/gearman-plugin-client# python gear_client.py -s
localhost --function=build:noop-check-communication' it could work.
But i hit gear errors
$ cat /var/log/zuul/gearman-server.log
2017-05-24 20:22:13,043 ERROR gear.Server: Exception in poll loop:
Traceback (most recent call last):
File "/usr/local/lib/python2.7/dist-packages/gear/__init__.py", line 2903, in
_doPollLoop
self.log.exception("Exception in poll loop:")
File "/usr/local/lib/python2.7/dist-packages/gear/__init__.py", line 2916, in
_pollLoop
for fd, event in ret:
IOError: [Errno 4] Interrupted system call
2017-05-24 20:22:14,081 ERROR gear.Server: Exception in poll loop:
Traceback (most recent call last):
File "/usr/local/lib/python2.7/dist-packages/gear/__init__.py", line 2903, in
_doPollLoop
self.log.exception("Exception in poll loop:")
File "/usr/local/lib/python2.7/dist-packages/gear/__init__.py", line 2916, in
_pollLoop
for fd, event in ret:
IOError: [Errno 4] Interrupted system call
Zuul logs like following:
2017-05-24 11:42:41,857 ERROR gear.Client.unknown: Exception in poll loop:
Traceback (most recent call last):
File "/usr/local/lib/python2.7/dist-packages/gear/__init__.py", line 830, in
_doPollLoop
try:
File "/usr/local/lib/python2.7/dist-packages/gear/__init__.py", line 856, in
_pollLoop
len(self.active_connections))
error: (4, 'Interrupted system call')
2017-05-24 11:45:24,565 INFO zuul.Server: Starting scheduler
2017-05-24 11:45:53,960 INFO zuul.Scheduler: Registering foreign project:
openstack/diskimage-builder
2017-05-24 11:45:54,417 INFO zuul.Scheduler: Registering foreign project:
openstack/nova
2017-05-24 11:46:03,840 INFO zuul.Scheduler: Registering foreign project:
openstack/openstack-helm
2017-05-24 11:46:10,344 INFO zuul.Scheduler: Registering foreign project:
openstack/daisycloud-core
2017-05-24 11:46:45,066 INFO zuul.Scheduler: Registering foreign project:
openstack/neutron-lib
2017-05-24 11:46:57,904 WARNING zuul.GerritEventConnector: Received
unrecognized event type 'ref-replicated' from Gerrit.Can
not get account information.
2017-05-24 11:46:58,045 WARNING zuul.GerritEventConnector: Received
unrecognized event type 'ref-replicated' from Gerrit.Can
not get account information.
2017-05-24 11:46:58,280 WARNING zuul.GerritEventConnector: Received
unrecognized event type 'ref-replicated' from Gerrit.Can
not get account information.
2017-05-24 11:46:58,422 WARNING zuul.GerritEventConnector: Received
unrecognized event type 'ref-replicated' from Gerrit.Can
not get account information.
2017-05-24 11:46:58,423 WARNING zuul.GerritEventConnector: Received
unrecognized event type 'ref-replicated' from Gerrit.Can
not get account information.
Any help is much appreciated!
Thanks,
Shilong
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
[OpenStack-Infra] [infra] lists.openstack.org maintenance Friday, May 26 20:00-21:00 UTC
The Mailman listserv on lists.openstack.org will be offline for an archive-related maintenance for up to an hour starting at 20:00 UTC May 26, this coming Friday. This activity is scheduled for a relatively low-volume period across our lists; during this time, most messages bound for the server will queue at the senders' MTAs until the server is back in service and so should not result in any obvious disruption. Apologies for cross-posting so widely, but we wanted to make sure copies of this announcement went to most of our higher-traffic lists. -- Jeremy Stanley signature.asc Description: Digital signature ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
[OpenStack-Infra] Zuul v3: proposed new Depends-On syntax
Hi, As part of Zuul v3, we're adding support for GitHub (and later possibly other systems). We want these systems to have access to the full power of cross-project-dependencies in the same way as Gerrit. However, the current syntax for the Depends-On footer is currently the Gerrit-specific change-id. We chose this in an attempt to be future-compatible with some proposed changes to Gerrit itself to support cross-project dependencies. Since then, Gerrit has gone in a different direction on this subject, so I no longer think we should weigh that very heavily. While Gerrit change ids can be used to identify one or more changes within a Gerrit installation, there is no comparable identifier on GitHub, as pull request numbers are unique only within a project. The natural way to identify a GitHub pull request is with its URL. This can be used to identify Gerrit changes as well, and will likely be well supported by other systems. Therefore, I propose we support URLs as the content of the Depends-On footers for all systems. E.g.: Depends-On: https://review.openstack.org/12345 Depends-On: https://github.com/ansible/ansible/pull/12345 Similarly to the Gerrit change IDs, these identifiers are easily navigable within Gerrit (and Gertty), so that reviewers can traverse the dependency chain easily. One substantial aspect of this change is that it is more specific about projects and branches. A single Gerrit change ID can refer to more than one branch, and even more than one project. Zuul interprets this as "this change depends on *all* of the changes that match". Often times that is convenient, but sometimes it is not. Frequently users ask "how can I make this depend only on a change to master, not the backport of the change to stable?" and the answer is, "you can't". URLs have the advantage of allowing users to be specific as to which instances of a given change are actually required. If, indeed, a change depends on more than one, of course a user can still add multiple Depends-On headers, one for each. It is also easy for Zuul connections to determine whether a given URL is referring to a change on that system without actually needing to query it. A Zuul connected to several code review systems can easy determine which to ask for the change by examining the hostname. URLs do have two disadvantages compared to Gerrit change IDs: they can not be generated ahead of time, and they are not as easily found in offline git history. With Gerrit change IDs, we can write several local changes, and before pushing them to Gerrit, add Depends-On headers since the change id is generated locally. URLs are not known until the changes are pushed to Gerrit (or GitHub pull requests opened). So in some cases, editing of an already existing commit message may be required. However, the most common case of a simple dependency chain can still be easily created by pushing one change up at a time. Change IDs, by virtue of being in the commit message of the dependent as well as depending change, become part of the permanent history of the project, no longer tied to the code review system, once they merge. This is an important thing to consider for long-running projects. URLs are less suitable for this, since they acquire their context from contemporaneous servers. However, Gerrit does record the review URL in git notes, so while it's not as convenient, with some additional tooling it should be possible to follow dependency paths with only the git history. Of course, this is not a change we can make instantaneously -- the change IDs have a lot of inertia and developer muscle memory. And we don't want changes that have been in progress for a while to suddenly be broken with the switch to v3. So we will need to support both syntaxes for some time. We could, indeed, support both syntaxes indefinitely, but I believe it would be better to plan on deprecating the Gerrit change ID syntax with an eye to eventually removing it. I think that ultimately, the URL syntax for Depends-On is more intuitive to a new user, especially one that may end up being exposed to a Zuul which connects to multiple systems. Having a Gerrit change depend on a GitHub pull request (and vice versa) will be one of the most powerful features of Zuul v3, and the syntax for that should be approachable. In short, I think the value of consistency across multiple backends and ease of use for new users outweighs the small loss of functionality for Gerrit power users in this case. I propose we adopt support for URLs in all source drivers in v3, and declare Gerrit change IDs deprecated. We will continue to support both for a generous deprecation period (at least 6 months after the initial Zuul 3.0 release), and then remove support for them. How does that sound? -Jim ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] Zuul v3: proposed new Depends-On syntax
From someone who has used/consumed/worked with/contributed to Zuul, this seems very straight forward and reasonable. The only concern is ensuring that the metadata on "if this has in-fact merged" is clearly available in the URL. I want to ensure we're implementing something generally useful and if the url cannot provide data on "if this thing is merged". As long as we have a clear "what we expect" and how to implement new URL data providers (I'm sure gerrit and github fundamentally provide different data in the web forms and we need to suss out grabbing relevant data), this is perfect. The downsides are relatively minimal (and could be solved with a wrapper to look at git-notes). I 100% agree we should not support all forms indefinitely, marking the gerrit change-id form as deprecated is a solid plan when coupled with this change. On Wed, May 24, 2017 at 4:04 PM, James E. Blair wrote: > Hi, > > As part of Zuul v3, we're adding support for GitHub (and later possibly > other systems). We want these systems to have access to the full power > of cross-project-dependencies in the same way as Gerrit. However, the > current syntax for the Depends-On footer is currently the > Gerrit-specific change-id. > > We chose this in an attempt to be future-compatible with some proposed > changes to Gerrit itself to support cross-project dependencies. Since > then, Gerrit has gone in a different direction on this subject, so I no > longer think we should weigh that very heavily. > > While Gerrit change ids can be used to identify one or more changes > within a Gerrit installation, there is no comparable identifier on > GitHub, as pull request numbers are unique only within a project. > > The natural way to identify a GitHub pull request is with its URL. > > This can be used to identify Gerrit changes as well, and will likely be > well supported by other systems. Therefore, I propose we support URLs > as the content of the Depends-On footers for all systems. E.g.: > > Depends-On: https://review.openstack.org/12345 > Depends-On: https://github.com/ansible/ansible/pull/12345 > > Similarly to the Gerrit change IDs, these identifiers are easily > navigable within Gerrit (and Gertty), so that reviewers can traverse the > dependency chain easily. > > One substantial aspect of this change is that it is more specific about > projects and branches. A single Gerrit change ID can refer to more than > one branch, and even more than one project. Zuul interprets this as > "this change depends on *all* of the changes that match". Often times > that is convenient, but sometimes it is not. Frequently users ask "how > can I make this depend only on a change to master, not the backport of > the change to stable?" and the answer is, "you can't". > > URLs have the advantage of allowing users to be specific as to which > instances of a given change are actually required. If, indeed, a change > depends on more than one, of course a user can still add multiple > Depends-On headers, one for each. > > It is also easy for Zuul connections to determine whether a given URL is > referring to a change on that system without actually needing to query > it. A Zuul connected to several code review systems can easy determine > which to ask for the change by examining the hostname. > > URLs do have two disadvantages compared to Gerrit change IDs: they can > not be generated ahead of time, and they are not as easily found in > offline git history. > > With Gerrit change IDs, we can write several local changes, and before > pushing them to Gerrit, add Depends-On headers since the change id is > generated locally. URLs are not known until the changes are pushed to > Gerrit (or GitHub pull requests opened). So in some cases, editing of > an already existing commit message may be required. However, the most > common case of a simple dependency chain can still be easily created by > pushing one change up at a time. > > Change IDs, by virtue of being in the commit message of the dependent as > well as depending change, become part of the permanent history of the > project, no longer tied to the code review system, once they merge. > This is an important thing to consider for long-running projects. URLs > are less suitable for this, since they acquire their context from > contemporaneous servers. However, Gerrit does record the review URL in > git notes, so while it's not as convenient, with some additional tooling > it should be possible to follow dependency paths with only the git > history. > > Of course, this is not a change we can make instantaneously -- the > change IDs have a lot of inertia and developer muscle memory. And we > don't want changes that have been in progress for a while to suddenly be > broken with the switch to v3. So we will need to support both syntaxes > for some time. > > We could, indeed, support both syntaxes indefinitely, but I believe it > would be better to plan on deprecating the Gerrit change ID syntax with >
Re: [OpenStack-Infra] Zuul v3: proposed new Depends-On syntax
On 2017-05-24 16:04:20 -0700 (-0700), James E. Blair wrote: [...] > How does that sound? I ain't afraid of no ghosts. Let's do it! -- Jeremy Stanley signature.asc Description: Digital signature ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] Zuul v3: proposed new Depends-On syntax
On May 24, 2017 11:04 pm, James E. Blair wrote: [...] How does that sound? Thinking about further connections support, could this also works for a (theorical) mail based patch cross dependency? What's the logic to match the Depends-On syntax to a connection driver? -Tristan pgprboWVzZLzx.pgp Description: PGP signature ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] Zuul v3: proposed new Depends-On syntax
On 2017-05-25 00:33:10 + (+), Tristan Cacqueray wrote: > On May 24, 2017 11:04 pm, James E. Blair wrote: > [...] > >How does that sound? > > Thinking about further connections support, could this also works > for a (theorical) mail based patch cross dependency? I can imagine wanting something like: Depends-On: https://lkml.org/lkml/diff/2017/5/24/668/1 ...where zuul will git am what it finds there. > What's the logic to match the Depends-On syntax to a connection > driver? This brings up an additional question: how far can we stretch the concept of a connection driver, and does it always need to be something we can report back on in some way? Maybe we want to test a Gerrit change or GutHub PR which requires a patch from the LKML (as above) when rebuilding the kernel for a guest, but we don't ever expect to report back to the LKML about anything. Would having a generic HTTP(S) driver for things like this make sense? -- Jeremy Stanley ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
