- 17 Feb, 2016 4 commits
-
-
Kirill Smelkov authored
To pick up kirr/gitlab-ce@32fa1180 /cc @kazuhiko, @jerome /reviewed-by TrustMe
-
Kirill Smelkov authored
6a4e45c5 (gitlab: Sync sidekiq service launch with upstream) claimed to sync sidekiq startup with upstream, but missed one upstream change in between 8.2 and 8.4: https://gitlab.com/gitlab-org/omnibus-gitlab/commit/2eb7634f My bad - I should have reviewed git log for https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/files/gitlab-cookbooks/gitlab/templates/default/sv-sidekiq-run.erb and I did not noticed that change because I did not and just compared queues list visually. Pick it up. /cc @kazuhiko, @jerome /reviewed-by TrustMe (I hope)
-
Rafael Monnerat authored
-
Kirill Smelkov authored
This brings slapos gitlab port up to date with current stable gitlab version 8.4, and teaches Unicorn startup script to wait a bit for PostgreSQL to start and be ready, before unicorn startup proceeds. /cc @kazuhiko /somewhat-reviewed-by @jerome /reviewed-on nexedi/slapos!44
-
- 16 Feb, 2016 3 commits
-
-
Alain Takoudjou authored
This changes were squashed into a single commit and it includes: - install slapos_configurator by default - Allow define ssl authentication for a certain zope family - Allow define custom zope path per zope family Those changes are originally written by Alain Takoudjou and rewrited by Rafael Monnerat
-
Kirill Smelkov authored
To pick up kirr/gitlab-ce@a5965b54.
-
Rafael Monnerat authored
The local changes are not yet generic enough to be shared among stack, so Introduce local changes here better
-
- 15 Feb, 2016 5 commits
-
-
-
Rafael Monnerat authored
-
Rafael Monnerat authored
There is no strong reason to use git.erp5.org to test code anymore
-
Rafael Monnerat authored
slapos.package is not an egg anymore, it's implementation was replaced by the usage of ansible with playbooks.
-
Rafael Monnerat authored
-
- 13 Feb, 2016 1 commit
-
-
Kirill Smelkov authored
As it was outlined in 5a744de7 (gitlab: Compile assets on instantiation and make sure DB is properly setup/migrated before unicorn runs) we are performing DB initialization and migration in pre-action as part of unicorn startup script. But that currently has one drawback: if all services start at the same time - e.g. both PostgreSQL and Unicorn - and that is a common scenario when SR is compiled and instantiated / started, PostgreSQL is usually not yet ready to process queries from Unicorn startup script, and first-time Unicorn startup fails. Until now this problem was workarounded by manually starting unicorn second time - after some time postgresql is started and ready. But why do it manually, if we can do the same logic automatically. So fix it: in Unicorn startup script wait a bit (up to 5 seconds) for PostgreSQL to become ready. /cc @kazuhiko, @jerome
-
- 12 Feb, 2016 2 commits
-
-
iv authored
This is a SR to build NayuOS binary images. More info on https://www.nayuos.com and in the README. Merging this recipe from a standalone repository was a decision made together with @kirr and @vpelletier.
-
iv authored
-
- 11 Feb, 2016 15 commits
-
-
Kirill Smelkov authored
Even though we do not use LFS objects, builds and build artifacts, gitlab backups corresponding directories and recreates them upon restore. Current state is: the directories are living under Rails root - that is in our gitlab-work/ inside instance, and since gitlab-work is recreated almost on every re-instantiation if we'll have some content in that directories - it will be lost. Don't allow even a chance for that to happen and move what is designed to hold data to under var/ . NOTE we create shared/lfs-objects/ and shared/artifacts/ because if we do not have this dirs, gitlab backup fails. Upstream code just assumes the directories are there. /cc @kazuhiko, @jerome
-
Kirill Smelkov authored
Upstream added `pages` and `elasticsearch` queues to sidekiq https://gitlab.com/gitlab-org/omnibus-gitlab/commit/be6844ff https://gitlab.com/gitlab-org/omnibus-gitlab/commit/801d6ed7 but since those queues are used for EE-only services we do not enable them. /cc @kazuhiko, @jerome
-
Kirill Smelkov authored
As gitlab-workhorse is now serving everything, it proxies unknown-to-it requests to unicorn, and that returns redirect to /users/sign_in for /non-existent, not 403. Adjust the promise and just verify whether we can get /static.css NOTE nginx promise now effectively depends on gitlab-workhorse being up and running - because nginx is now configured to be only an SSL terminator and all requests processing is done by gitlab-workhorse and services below it. If in the future we'll need a pure nginx-is-up promise, we can introduce something to nginx config and verify that particular http endpoint. /cc @kazuhiko, @jerome
-
Kirill Smelkov authored
add `-documentRoot ...` argument to gitlab-workhorse start as upstream started to do: https://gitlab.com/gitlab-org/omnibus-gitlab/commit/d769f751 ( gitlab-workhorse now needs to know where document root is as it now serves all content - e.g. static files too this option was introduced here: https://gitlab.com/gitlab-org/gitlab-workhorse/commit/1a7009e4 ) /cc @kazuhiko, @jerome
-
Kirill Smelkov authored
I manually reviewed files/gitlab-config-template/gitlab.rb.template files/gitlab-cookbooks/gitlab/attributes/default.rb from omnibus-gitlab 8.4.2+ce.0-3-g68d5ee8 and picked up changes: - unicorn OOM killer memory limits were raised up (because gitlab is now more memory hungry according to talks on gitlab.com) https://gitlab.com/gitlab-org/omnibus-gitlab/commit/f8ee4a19 - there is no default limit for nginx client_max_body_size - it just goes to gitlab-workhorse as is at any size https://gitlab.com/gitlab-org/omnibus-gitlab/commit/78862837 /cc @kazuhiko, @jerome
-
Kirill Smelkov authored
Direct merge for gitconfig.erb from omnibus-gitlab did not brought up updates. pack.threads=1 and receive.fsckObjects=true picked up from https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/files/gitlab-cookbooks/gitlab/attributes/default.rb in 264d785a stay the same. /cc @kazuhiko, @jerome
-
Kirill Smelkov authored
No changes. /cc @kazuhiko, @jerome
-
Kirill Smelkov authored
- there is a section for gitlab pages, which we stub-out; - there is no longer a need to add /raw/... handling to nginx - as now nginx is just an SSL terminator for gitlab-workhorse, all URL handling is done inside gitlab-workhorse and is dealt with ok by our patches. - as now nginx does not directly connect to unicorn, there is no need to pass unicorn section to nginx's template. /cc @kazuhiko, @jerome
-
Kirill Smelkov authored
Like wih gitlab configs, this does only pure merge. We will slaposify / adjust to updates in the following patches. /cc @kazuhiko, @jerome
-
Kirill Smelkov authored
Slapos'ify config updates brought by sync with omnibus-gitlab (see merge in the previous patch). Changes: - default visibility levels gone away (see merge commit and https://gitlab.com/gitlab-org/omnibus-gitlab/commit/b5ebbab3 ) - there are new settings for GitLab Pages and Elasticsearch, which are EE only and thus we do not support them. - there are new settings for auxiliary cron-like jobs, which we do not support for now, since they are used either for CI (not supported by us) or EE features. Configuration files that were synced, but did not changed are also marked as updated, so it is easier to track their changes to upstream in the future. /cc @kazuhiko, @jerome
-
Kirill Smelkov authored
This does only pure merge. We will slaposify / adjust config and corresponding md5sum in the following patches. /cc @kazuhiko, @jerome
-
Kirill Smelkov authored
Like 8f945bd2 - pristine copy from omnibus 8.4.4+ce.0-0-g1680742. Nothing changed at all - gitconfig.erb stays the same. /cc @kazuhiko, @jerome
-
Kirill Smelkov authored
Like 61544d87 - pristine copy from omnibus 8.4.4+ce.0-0-g1680742. Most of http handling is moving to gitlab-workhorse. Nginx remains only as ssl terminator. /cc @kazuhiko, @jerome
-
Kirill Smelkov authored
Like 6fd7b987 - pristine copy from omnibus 8.4.4+ce.0-0-g1680742. The only change is in gitlab.yml The following files stay the same: database.yml.erb gitlab-rails-config.ru.erb gitlab-shell-config.yml.erb rack_attack.rb.erb resque.yml.erb smtp_settings.rb.erb unicorn.rb.erb /cc @kazuhiko, @jerome
-
Kirill Smelkov authored
Update GitLab software to - gitlab-ce 8.4 + NXD patches https://lab.nexedi.com/kirr/gitlab-ce/commits/8-4-nxd - gitlab-shell to 2.6.10 which now is pure upstream, as all NXD patches were merged. - gitlab-workhorse 0.6.X + NXD patches. https://lab.nexedi.com/kirr/gitlab-workhorse/commits/y/blobraw-3 https://gitlab.com/gitlab-org/gitlab-workhorse/merge_requests/17 This only updates software and begins SR update to 8.4 - for now gitlab instance becomes non-working -- we'll pull in configuration files updates and fixups in the following patches. /cc @kazuhiko, @jerome
-
- 10 Feb, 2016 2 commits
-
-
iv authored
-
Jérome Perrin authored
slapos.recipe.cmmi executes command lines by line, so this build options were ignored.
-
- 09 Feb, 2016 2 commits
-
-
Rafael Monnerat authored
older versions are failing on ARM arch.
-
iv authored
-
- 08 Feb, 2016 1 commit
-
-
iv authored
-
- 02 Feb, 2016 2 commits
-
-
Kazuhiko Shiozaki authored
version up : OpenBLAS 0.2.15. First try with auto-detected target and if it fails try TARGET=GENERIC. You can also spcify the target explicitly by build-ext-options. reviewd-by @Tyagov (on nexedi/slapos!42).
-
Kazuhiko Shiozaki authored
-
- 01 Feb, 2016 3 commits
-
-
Kirill Smelkov authored
This patch series teaches ERP5 software release to automatically instantiate Jupyter notebook web UI and tune it to connect to ERP5 by default. When Jupyter is enabled, it also installs on-server erp5_data_notebook bt5 (see nexedi/erp5!29 and nexedi/erp5@f662b5a2) which handles code execution requested for Jupyter. For ERP5 - for security and backward compatibility reasons - Jupyter instantiation and erp5_data_notebook bt5 install happen only if jupyter is explicitly enabled in instance parameters. The default is not to have Jupyter out of the box. On the other hand for Wendelin SR, which inherits from ERP5 SR, the default is to have Jupyter out of the box, because Wendelin SR is fresh enough without lots of backward compatibility needs, and Jupyter is usually very handy for people who use Wendelin. -------- NOTE Currently erp5-data-notebook bt5 has the following limitations (see details on nexedi/slapos!43 and nexedi/erp5!29): - errors are not reported properly to users; - state is not fully saved to ZODB. the latter point means notebook works only if it is connected to Zope family with only 1 zope process. Hopefully this will be resolved some day. Technical overview about how the integration is done itself on slapos part and other notes are in 0a446263. /proposed-for-review-on nexedi/slapos!43
-
Douglas authored
Query strings used on GET requests have size limitations on servers and this causes big code cells to not be executed at all, returning only an Internal Server Error with no further explanation. /reviewed-by @kirr, @Tyagov (on nexedi/slapos!43)
-
Kirill Smelkov authored
Pandas and scikit-learn are handy to have for data processing which we are going to do more and more in ERP5 context. Matplotlib is very handy to have when one works with Jupyter, but also can be used by just backend code to generate graphs. From this point of view it makes sense to have this eggs always available out of the box. To do so move them from Wendelin to ERP5. /suggested-by @tiwariayush /reviewed-by @Tyagov (on nexedi/slapos!43)
-