codeenigma / ce-vm Goto Github PK

We had removed https://github.com/codeenigma/ce_deploy from composer.json, but should reintroduce it.

When I try to do a vagrant up, I receive an error:

Stderr: Error response from daemon: endpoint with name ***** already exists in network ce-vm-192.168.57.0/24

If I retry vagrant up, it works correctly but it fails in the next docker machine. I have tried removing network and containers but it doesn't solve the problem.

Hi,

Client has asked:

Is it possible to have 'convert' installed on to the vm, so we have the same imagemagick setup on all our environments?

I guess it is, thought a GitHub issue makes most sense! :-)

Thanks,

Greg

Some of the Solr modules in drupal (https://www.drupal.org/project/search_api_solr/releases/8.x-3.9) are not supporting Solr 4.x. I have tried to make Solr machine works with this version but looks like Solr Package structure is a little bit different. We would need to review what is failing when we change Solr version and it makes our version doesn't work.

Drush 9 support in the generated defaults lags behind (typically, drush aliases are still using older format).

Provide something along the lines of vagrant-cachier for as many things as possible

The Network part at http://ce-vm.readthedocs.io/en/latest/stack/db/ seems outdated, or simply that it was done via copy&paste from the "App" instance. PR fixing it: #36

We replaced at some point the use of the contrib vagrant-triggers plugin with raw calls so system exec, due to version issues between the plugin and Vagrant itself.
Now that triggers have moved to core Vagrant, we should leverage them back.

Using Docker on Linux is only do-able currently if you user is 1000. Having vagrant uid as a setting would allow other combinations.

The way we auto install the vagrant-hostsupdater plugin is no longer compatible with newer version of Vagrant.

We currently rely on Ansible for any customisation that is not available from variables. While this is powerful and flexible, it also can be daunting/scary for some users.
We could provide a simpler way to take over some configuration files, by copying files from project to container based on naming/folder convention. Proposed structure:

<project_root>/ce-vm/overrides/<service_name>/target/structure/on/the/guest/file.ext

That means that a file created on the host as:

./ce-vm/overrides/fpm/etc/php/7.0/fpm/php.ini

Would be copied over to:

/etc/php/7.0/fpm/php.ini

on the guest.

This should probably happen as the last part of the default provisioning, before services are restarted (?)

It would be useful if database connection details and credentials could be added to the dashboard.

Once we have #40 in place, we should allow commands to be run for each service (or globally) at each steps of the triggers.
Those would be defined as a nested list in the .yml configs, eg something along the lines of:

vagrant_triggers:
  - up:
    - "my command one to run on host"
    - "a second command"

The auto pulling of minor versions in the ce-vm-upstream clone no longer works.

The way we currently run tests only tests that the containers get run and provisioned properly, but nothing functional beyond that.
We could leverage the nightwatch container to perform more elaborate tests.

This kills vagrant up for elastic vm on a Mac for me (MacOS 10.14, Docker Desktop Community Version 2.0.0.2):

I get the following error:

==> elastic: Running trigger...
    elastic: Running local: Inline script
    elastic: sudo sysctl -w vm.max_map_count=262144
    elastic: sysctl: unknown oid 'vm.max_map_count'
==> elastic: Trigger run failed
==> elastic: A script exited with an unacceptable exit code 1.
A script exited with an unacceptable exit code 1.

It seems it's trying to set it for the Mac host (not Linux), which would not have the desired effect. An manual approach, which does seem to work for me is this: https://stackoverflow.com/a/51623813/2682119

Workaround I'm using for this is just overriding vagrant_triggers_mac_os in an local/service.elastic.yml file.

When running tests through Travis for a PR, we actually don't run the tests on the right branch. The current major branch is harcdoded in https://github.com/codeenigma/ce-vm/blob/5.x/tests/test.sh#L30, leading to tests to be run against it instead of the target branch.
We should instead use the current branch (see https://graysonkoonce.com/getting-the-current-branch-name-during-a-pull-request-in-travis-ci/ and travis-ci/travis-ci#6652) when available.
We can use that in 2 ways:

• we create a matching branch in ce-vm-model before each PR and adjust the file accordingly.
• we replace the branch (sed or something) in the file from the main branch (probably better).

With the switch to domain being configurable, we need a way to re-generate ssl certs to match the config used.

How to recreate:

• Provision a server with php 7.0
• Change php_version to another version (eg. 5.6)
• Reprovision the server

Result

• Web server uses the chosen version of php correctly
• cli is stuck on the original version chosen (7.0)

We currently only can add additional services that are based on our base image (with SSH, ansible, ...). While it ensure consistency, it sometime is an overkill.
We should make it possible to add a service.XXX.yml that simply declare the use of another image. Using the docker_extras_args, and the networx related service only, this should be fairly do-able.
We need to introduce an additonal variable (managed: no or whatever we want to name it), that we can use in the vagrantfile to skip anything relating to SSH and provisioning.

When running behing a proxy on a server, we don't want to use the host updater plugin at all.