-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Juju times out fetching charm metadata #551
Comments
There are some speed improvements that need to be done to the charmstore but in the meantime you can start by not requesting so much information in that request. To deploy a charm you shouldn't need a number of those pieces of data. Especially things like |
I still get "0 items" pretty frequently at https://jujucharms.com/u/openstack-charmers-next - could this be related? |
The charm store often does not respond in 5s. Increase the timeout to 20s. Charm store issue being tracked in canonical/jujucharms.com#551 . Closes issue 261.
* Increase the timeout for charmstore connections The charm store often does not respond in 5s. Increase the timeout to 20s. Charm store issue being tracked in canonical/jujucharms.com#551 . Closes issue 261. * Allow charm store timeout to be configurable
Adjusting to 30 seconds for this query also is timing out: theblues.errors.ServerError: Request timed out: https://api.jujucharms.com/charmstore/v5/~openstack-charmers-next/bionic/neutron-gateway/meta/any?include=bundle-machine-count&include=bundle-metadata&include=bundle-unit-count&include=bundles-containing&include=charm-actions&include=charm-config&include=charm-metadata&include=common-info&include=extra-info&include=revision-info&include=stats&include=supported-series&include=manifest&include=tags&include=promulgated&include=perm&include=id timeout: 30.0 It's breaking tooling all over. What is the expected time that this query should take, please? |
More timeouts
|
The CS: timeout issues are prevalent in our CI as well. So to summarize: end users browsing jujucharms.com have a frequent error condition (0 items shown), conjure-up has a high failure rate for end users, my developers are often blocked merges which cannot complete a CI test. Please investigate the back-end of CS. |
The culprit largely seems to be the stats component of queries on the charmstore. If possible omitting stats from the include in query params can speed things up considerably. @fnordahl @ajkavanagh -- we are working on a deploy of jujucharms.com that should fix searching through the site, using the stats omission workaround. @ajkavanagh @ryan-beisner @ChrisMacNaughton is the stats data necessary for your current uses? If not I would recommend removing it. Charmstore folks are working on the issue as well, but in the meantime this approach could mitigate the problems. |
Make it possible to disable stats collection canonical/jujucharms.com#551
@Jaycee That library has been in place as-is, for better or for worse, for quite some time. What has changed that suddenly causes this to be an issue? We can, should and will adjust the theblues library. However, it's a messy sprawl of impact. In order to actually profit, conjure-up and other projects will need to be rebuilt and redistributed with the modified theblues project. Also, other consumers of the theblues library will need to be modified to turn off stats, then and those modified projects will need to be redistributed/released. |
FTR, bundletester, amulet also affected:
|
@ryan-beisner The stats component of the charmstore has always been slow; however, there's presently some issue going on with the underlying tools charmstore relies on causing a general slow down, which exacerbates the stats to the point that we're seeing these slowdowns. theblues has been updated w/ @ChrisMacNaughton's fix: https://pypi.org/project/theblues/ Additionally, the fix is now live on jujucharms.com |
@Jaycee Even though theblues is released with the update, the default behavior of it was not changed. That means that we will have to go find all of the calls to theblues in intermediate modules such as amulet, bundletester, and other tools, modify them to tell theblues not to ask for stats, then release those individual intermediate tools. FTR, we are still seeing prevalent CS timeouts overnight 2018 Sept 18 to 19. |
I'm aware that the change is going to need to be made--as I understand it fixes are already underway for python-jujulib and amulet. The underlying issues on CS are to my knowledge still being worked on--it requires a sizeable amount of work. I would encourage you to make the updates to use theblues b/c the CS fixes may take some time to rollout. |
Indeed, we have all of that in flight. Just commenting here so passers-by understand that the theblues changes alone are not going to unblock devs and ci. |
Ah, ok, I'm with you now. Thanks! |
I'm still hitting >10s response times. You can see it in a openstack review https://openstack-ci-reports.ubuntu.com/artifacts/test_charm_pipeline_amulet_full/openstack/charm-aodh/603318/7/2056/test_charm_amulet_full_4171/amulet-full.txt . Also a curl command takes >10s:
|
@Jaycee ^ that is with stats disabled. We are still hitting prevalent CS timeouts. In an openstack deploy, with ~40 charms, all it takes is 1 charm query to fail to spoil an expensive and lengthy CI run. The result is that our devs cannot get code through our gate to land code currently. |
Conjure up regularly fails with a timeout fetching charm metadata during a deploy. This makes it impossible to use conjure-up to deploy any solution as the charms are unavailable.
The text was updated successfully, but these errors were encountered: