Code Monkey home page Code Monkey logo

st2-packages's Introduction

Stackstorm packages build environment

Circle CI Build Status Go to Docker Hub Download deb/rpm

Highlights

  • Docker based. Leveraging docker it's possible to deliver packages for any OS distro in a fast and reliable way. Use the latest Docker version with a Docker Compose plugin that supports V2 syntax.
  • Rake + sshkit-based execution enables easy configuration via simple DSL and brings parallel task processing out of the box.
  • Test-driven workflow. Artifacts built are not only available for any enabled OS distro but at the same time tested on a bunch of platforms, providing feedback such as can be installed, services can start up, operations can be executed etc.

Overview

Packages build environment is a multi-container docker application defined and managed with docker-compose. It consists of four types of containers:

  • Packaging runner (https://quay.io/stackstorm/packagingrunner) - the main entry point, package build and test processing controller container.
  • Packaging build (https://hub.docker.com/r/stackstorm/packagingbuild/) - container where actual .deb/.rpm artifacts build takes place. It's used to bring up the build environment specific for OS distro. This means that different containers are available such as packagingbuild:rocky8, packagingbuild:focal correspondingly for RockyLinux 8 and Ubuntu Focal.
  • Packaging test (https://hub.docker.com/r/stackstorm/packagingtest/) - containers where built artifacts are tested, i.e. artifacts are installed, configuration is written and tests are performed.
  • Services - these are different containers required for testing such as rabbitmq and mongodb

Dockerfiles sources are available at StackStorm/st2-dockerfiles.

The Packages build environment compose application brings a self-sufficient pipeline to deliver ready to use packages.

Usage

It's very simple to invoke the whole build-test pipeline. First just make sure that docker-compose.yml has your distro specification, after that issue the following commands:

# (Optional) First clean out previous build containers
docker compose kill
docker compose rm -f

# To build packages for ubuntu focal (--rm will wipe packaging runner container. All others will remain active).
docker compose run --rm focal

Execution takes a while, so grab a cup of tea or coffee and wait until it finishes. When build and test processes succeed, you'll find the StackStorm packages in /tmp/st2-packages on your host machine:

ls -l1 | grep ".deb$"
-rw-r--r-- 1 root root 30872652 Feb  9 18:32 st2_1.4dev-1_amd64.deb

Manual testing inside the docker environment

After the build and test stages are finished all docker containers remain active, so you are welcome to do more in-depth testing if desired. To do so simply run:

docker ps
# Find the required testing container
# In our case it will be st2packages_focaltest_1

# Simply exec to docker
docker exec -it st2packages_focaltest_1 bash

Once done, you are inside the testing environment where all services are up and running. Don't forget to do (after exec):

export TERM=xterm

At this point you can do any manual testing which is required.

Vagrant based build and test

In order to build, package, install and test ST2 in an isolated Vagrant VM, run the following:

vagrant up $TARGET

Where $TARGET is one of focal, or el8 or el9. If you are using el8, comment out the vm_config.vm.provision :docker line in the Vagrantfile. There is logic in setup-vagrant.sh to install docker in el8.

The following steps are run while provisioning the Vagrant VM:

  1. Install docker that includes docker compose V2.
  2. Run docker compose run --rm $TARGET to build, test and package ST2 as described in prior sections.
  3. Install the packages built in step 2, unless the host $ST2_INSTALL environment variable is set to a value other than yes.
  4. Execute the st2-self-check script, unless the host $ST2_VERIFY environment variable is set to a value other than yes.

As currently implemented, it is not possible to bypass steps 1 and 2. In the future, we may want to consider allowing the host to provide existing ST2 packages, and install/self-check those in the Vagrant VM.

To specify the ST2 source URL and REV (i.e., branch), use ST2_GITURL and ST2_GITREV environment variables on the host prior to provisioning the VM.

Prior to running st2-self-check, the required auth token is generated using st2 auth. If necessary, you can change the default username and password passed to st2 auth. To do this, set the ST2USER and ST2PASSWORD environment variables on the host prior to provisioning the VM. The default values are st2admin and Ch@ngeMe respectively.

Installation

Current community packages are hosted on https://packagecloud.io/StackStorm. For detailed instructions how install st2 and perform basic configuration follow these instructions:

Adding Support For a New Distribution

If you are adding support for a new distribution for which packagingbuild and packagingtest images are not yet published to Docker Hub and you want to test the build pipeline locally, you need to update docker-compose.yml file to use locally built Docker images.

For example:

...

focal:
  ...
  image: quay.io/stackstorm/packagingrunner
  ...
...

focalbuild:
  ...
  image: focalbuild
  ...

...

focaltest:
  ...
  image: focaltest
  ...

NOTE: Main distro definition (e.g. focal, el8 etc.) needs to use packaging runner image.

As you can see, image attribute references local image tagged focalbuild instead of a remote image (e.g. stackstorm/packagingbuild:focal or similar).

Before that will work, you of course also need to build those images locally.

For example:

cd ~/st2packaging-dockerfiles/packagingbuild/focal
docker build -t focalbuild .

cd ~/st2packaging-dockerfiles/packagingtest/focal/systemd
docker build -t focaltest .

License and Authors

st2-packages's People

Contributors

amanda11 avatar andymoore avatar arm4b avatar armab avatar ashleydumaine avatar bigmstone avatar blag avatar cognifloyd avatar dbarrosop avatar dennybaa avatar emedvedev avatar enykeev avatar eorochena avatar guzzijones avatar humblearner avatar jjm avatar kami avatar khaddict avatar lakshmi-kannan avatar lindsayhill avatar m4dcoder avatar manasdk avatar mierdin avatar nmaludy avatar nzlosh avatar punkrokk avatar shivani-orch avatar userlocalhost avatar warrenvw avatar winem avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

st2-packages's Issues

New Packages and st2ctl

Core Action st2 packs.restart_component and st2 packs depends on st2ctl script, which doesn't exist in new packages system, because of new shiny init/upstrart startup scripts.

Not sure about current/future plans about st2ctl.
Or we should still ship st2ctl, or edit st2 core actions:

And other occurencies: https://github.com/StackStorm/st2/search?p=1&q=st2ctl&utf8=%E2%9C%93

If edit st2 actions, - then new release version should be shipped only with new Packages and startup scripts.

Reproduce:

$ st2 run packs.restart_component servicename=st2auth
.
id: 567583ff73b55b33b955b0a4
status: failed
parameters:
  servicename: st2auth
result:
  failed: true
  return_code: 127
  stderr: 'bash: st2ctl: command not found'
  stdout: ''
  succeeded: false

"ERROR: HTTPConnectionPool(host='127.0.0.1', port=9101)" with gunicorn

it7dra4 1

For some still unknown reason there is a ghost bug, appearing rarely when st2api with recent gunicorn change is not reachable by port (service is starting OK).

Actually, we're not even sure if st2auth is reachable at all, because there are no tests.
We have the tests now.

Cache pip between builds

One of future non-priority optimizations

Pip downloads are pretty time-consuming, especially when there are big amount of packages.
Since we discovered that pip has lock problems and can't be parallelized during the concurrent package builds, one of possible options to improve the #7 speed among #11 and #13 is to cache pip downloads everywhere where it's possible to do by.

Share ~/.cache/pip between running Docker containers (build containers/test containers),
so hopefully we won't download same packages every time again and again.

"Failed to fetch" for Bintray Wheezy repo

Package installing from Bintray fails on Debian Wheezy.

Repro

apt-get install python-software-properties

wget -qO - https://bintray.com/user/downloadSubjectPublicKey?username=bintray | apt-key add -
add-apt-repository 'deb http://dl.bintray.com/stackstorm/wheezy_staging unstable main'
apt-get update

Error

W: Failed to fetch http://dl.bintray.com/stackstorm/wheezy_staging/dists/unstable/Release  Unable to find expected entry 'main/source/Sources' in Release file (W               rong sources.list entry or malformed file)

E: Some index files failed to download. They have been ignored, or old ones used instead.

ubuntu start-stop-daemon invocation

trusty docker container:
/etc/init.d/st2sensorcontainer stop

start-stop-daemon: warning: this system is not able to track process names
longer than 15 characters, please use --exec instead of --name.

sensorcontainer ubuntu initd service [python] <defunct>

After exiting of sensorcontainer defunt can be seen in ps -A uxw
Repro: trusty container

/etc/init.d/st2sensorcontainer start
ps -A uxw
tail -f /var/log/st2/st2sensorcontainer.log

>>>
2015-12-23 17:34:09,846 140045084577136 WARNING api [-] "auth.api_url" configuration option is not configured
2015-12-23 17:34:09,863 140045084577616 INFO mixins [-] Connected to amqp://guest:**@127.0.0.1:5672//
2015-12-23 17:34:09,866 140045084577136 INFO log [-] Sensor linux.FileWatchSensor started
2015-12-23 17:34:14,867 140045084577136 INFO log [-] Process for sensor linux.FileWatchSensor has exited with code 1
2015-12-23 17:34:17,381 140045084576976 AUDIT log [-] Access granted to "sensors_container" with the token set to expire at "2015-12-24T17:34:17.379757Z". (username='sensors_container',token_expiration='2015-12-24T17:34:17.379757Z')
2015-12-23 17:34:17,382 140045084576976 WARNING api [-] "auth.api_url" configuration option is not configured
2015-12-23 17:34:19,874 140045084577136 INFO log [-] Process for sensor linux.FileWatchSensor has exited with code 1
2015-12-23 17:34:24,891 140045084576976 AUDIT log [-] Access granted to "sensors_container" with the token set to expire at "2015-12-24T17:34:24.888881Z". (username='sensors_container',token_expiration='2015-12-24T17:34:24.888881Z')
2015-12-23 17:34:24,892 140045084576976 WARNING api [-] "auth.api_url" configuration option is not configured
2015-12-23 17:34:29,882 140045084577136 INFO log [-] Process for sensor linux.FileWatchSensor has exited with code 1

Pass $ST2_RELEASE to docker-compose from CI

Add ability to pass revision number aka release number from CI, to control package versioning.

st2api_0.14dev-20_amd64.deb

So the version number 0.14dev is parsed from st2common automatically and revision number 20 is injected from outside via ENV.

Same as we have for mistral in docker-compose.

docker-compose should pick up env via docker/compose#1765 when using:

export ST2_RELEASE=20
docker-compose up debian

^^ I'm happy that feature with ENV variables was introduced in docker-compose and released in 1.5 version just hours ago. We're lucky here ๐Ÿ€

Docs: https://github.com/docker/compose/blob/8cc8e61/docs/compose-file.md#variable-substitution

Info: DroneCI v0.3

Comparing to v0.4, Drone v0.3 doesn't support build matrix.

0.4 stable is just released yesterday and drone/drone master just migrated to the new codebase, meaning v0.3 is considered unsupported/outdated from now.

Sadly we can't use 0.4 because of issues described #9. However there were some crazy ideas to make v0.3 working.

So the idea is: Instead of relying on v0.4 matrix, we can just run needed number of DroneCI instances simultaneously and connect them with our GitHub repo, so they would run in parallel.
Golang hacks arm4b/drone#1 and arm4b/drone#2 made it possible (TBH this is my first Golang touch). So I built it from sources and ran 3 different drone instances with 3 different configs.

Worked surprisingly well on one AWS server and looks nice:

Now we have 3 configs for every build instead of one .drone.yml:

Pros

  • self-hosted CI, - this is really cool and brings full control
  • we can add custom logic by editing sources (limited to Golang skills)
  • show different statuses in Pull Requests for every distro. This is rocking hack, which is not possible with any 3rd party CI. I especially like it, because it gives status about every distro ASAP (the screenshot demonstrates it well).

Cons

  • v0.3 is outdated, meaning it will become more and more obsolete and unsupported with time
  • there is no option to run deploy section when all builds were successfull, as we have in CircleCI #6. We need something like this to upload artifacts only when everything went well
  • linked services have no additional settings: no shared volumes, no custom ports or commands
  • because of ^^ there are differencies in running docker-compose and drone. I would prefer ability to 100% reproduce local and CI builds. For example there are small (solvable) problems running centos7 and debian builds.
  • no good API and documentation

References

Conclusion

With possibility to run builds in parallel and even with limitations described, Drone v0.3 looks like one of possible solutions, same as CircleCI, both with its unique features.

  • Drone v0.3
    • self-hosted CI, OpenSource, we can change it (Golang), but very minimal in features
    • parallel builds with hack, custom Github PR status for every build in matrix
    • fast if we host it on good server
    • no bult-in docker-compose, because of drone configs, meaning no reproduceable local and CI builds
    • needs some fixes, needs setup and maintenance
  • CircleCI
    • 3rd-party CI service, no way to change it, but very flexible with tonns of features
    • built-in parallel builds
    • fast, 32CPUs for every build machine and a lot of memory. 4 free parallel slots (VMs) for OSS
    • docker-compose support, meaning 100% reproduce local and CI builds, ssh debug mode
    • good API, ability to trigger builds with custom parameters
    • works well with almost no efforts, saves time.

Parallel package builds

Current build process pipeline is in bash, and it's nightmare to support it. Introducing parallel package build will bring more bash hardcore code. We should waste the current build controlling code in favor of a better solution.

To leverage parallel package build (need by #7) the best option is to use flow based build tool with support for dependencies and parallelism. The current vision is to use rake + sshkit.
Rake is a prefect candidate since it's provides a very rich set of features and it has a very simple DSL.


Other python based solutions will take more effort to use. There are following options:

Unluckily all of the python based tools either lack needed parallelism or just quite heavy to use...

setup_virtualenv.py fails on el7

  File "/usr/share/python/st2actions/lib/python2.7/site-packages/virtualenv.py", line 1192, in install_python
    copy_required_modules(home_dir, symlink)
  File "/usr/share/python/st2actions/lib/python2.7/site-packages/virtualenv.py", line 1131, in copy_required_modules
    copyfile(filename, dst_filename, symlink)
  File "/usr/share/python/st2actions/lib/python2.7/site-packages/virtualenv.py", line 468, in copyfile
    os.makedirs(os.path.dirname(dest))
  File "/usr/share/python/st2actions/lib64/python2.7/os.py", line 157, in makedirs
    mkdir(name, mode)
OSError: [Errno 2] No such file or directory: '/opt/stackstorm/virtualenvs/github/lib64/python2.7'

related #53

Bintray doesn't sign RPM packages

Seems Bintray can't sign .rpm packages during upload.
It does it well for .deb packages.


Repo: https://bintray.com/stackstorm/el7_staging

Bintray UI for el7_staging repo

edit_-_2015-12-17_18 54 12

Adding repository

/etc/yum.repos.d/StackStorm-el7_staging.repo:

[StackStorm-el7_staging]
name=StackStorm-el7_staging
baseurl=https://dl.bintray.com/stackstorm/el7_staging/unstable
gpgcheck=1
gpgkey=https://bintray.com/user/downloadSubjectPublicKey?username=bintray
enabled=1

Installing package

# yum install st2common

Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
 * base: ftp.heanet.ie
 * extras: ftp.heanet.ie
 * updates: ftp.heanet.ie
Resolving Dependencies
--> Running transaction check
---> Package st2common.x86_64 0:1.3dev-2 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

==============================================================================================================================================
 Package                        Arch                        Version                         Repository                                   Size
==============================================================================================================================================
Installing:
 st2common                      x86_64                      1.3dev-2                        stackstorm-el7_staging                       17 M

Transaction Summary
==============================================================================================================================================
Install  1 Package

Total size: 17 M
Installed size: 69 M
Is this ok [y/d/N]: y
Downloading packages:


Package st2common-1.3dev-2.x86_64.rpm is not signed

Verify if package signed

# wget https://dl.bintray.com/stackstorm/el7_staging/unstable/st2common-1.3dev-2.x86_64.rpm
# rpm -qpi *.rpm | awk '/Signature/'

Signature   : (none)

Additional resources (not to forget):


TODO:

  • Dig into RPM signing/docs/specs later
  • Contact Bintray support.

st2mistral package

Okay we need a package for st2mistral which is basically a plugin for OpenStack Mistral.

The purposed way is to pre-package a wheel into deb/rpm packages, and inject that wheel into the mistral virtualenv (provided bundled mistral package by st2) and also to inject into site-packages if python-mistral native debian package is installed.

This method is easy to go and it should work in 80% (presumably ะ–).

Pros

  • it'll work for mistral bundled by st2 team 100%.
  • it should reliably work if mistral installed system-wide using pip or even python-mistral package. (but yeah guys no guaranties).

Cons

  • It of course won't work for any custom mistral installations using their own virtual environments.

cc: @lakshmi-kannan, @m4dcoder

Cheers!

ImportError: No module named st2actions via script `st2-register-content`

When running st2-register-content script it shows ImportError for st2actions module.

It's interesting, when I install st2bundle instead of st2api st2actions st2auth st2client st2common st2debug st2exporter st2reactor, I don't get this error.
So I assume it's realted to new virtualenv/packages system.

Reproduce (Ubuntu14):

# Add Bintray unstable repo
wget -qO - https://bintray.com/user/downloadSubjectPublicKey?username=bintray | apt-key add -
add-apt-repository 'deb https://dl.bintray.com/stackstorm/trusty_staging unstable main'

# Install Rabbit and Mongo
apt-get update
apt-get install rabbitmq-server mongodb-server

# Install st2
apt-get install st2api st2actions st2auth st2client st2common st2debug st2exporter st2reactor

# Set `enable = False` under `[auth]` section in file: `/etc/st2/st2/conf`
sudo sed -i '/^\[auth\]$/,/^\[/ s/^enable = True/enable = False/' /etc/st2/st2.conf

# Register content
st2-register-content --register-all --config-dir /etc/st2
Error:
$ st2-register-content --register-all --config-dir /etc/st2

2015-12-19 18:06:23,156 INFO [-] Connecting to database "st2" @ "0.0.0.0:27017" as user "None".
2015-12-19 18:06:23,259 INFO [-] =========================================================
2015-12-19 18:06:23,260 INFO [-] ############## Registering sensors ######################
2015-12-19 18:06:23,260 INFO [-] =========================================================
2015-12-19 18:06:23,297 INFO [-] Registered 1 sensors.
2015-12-19 18:06:23,297 INFO [-] =========================================================
2015-12-19 18:06:23,297 INFO [-] ############## Registering actions ######################
2015-12-19 18:06:23,297 INFO [-] =========================================================
2015-12-19 18:06:24,042 INFO [-] Registered 40 actions.
2015-12-19 18:06:24,042 INFO [-] =========================================================
2015-12-19 18:06:24,042 INFO [-] ############## Registering rules ########################
2015-12-19 18:06:24,043 INFO [-] =========================================================
2015-12-19 18:06:24,049 INFO [-] Registered 0 rules.
2015-12-19 18:06:24,049 INFO [-] =========================================================
2015-12-19 18:06:24,049 INFO [-] ############## Registering aliases ######################
2015-12-19 18:06:24,049 INFO [-] =========================================================
2015-12-19 18:06:24,059 INFO [-] Registered 2 aliases.
2015-12-19 18:06:24,059 INFO [-] =========================================================
2015-12-19 18:06:24,059 INFO [-] ############## Registering policy types #################
2015-12-19 18:06:24,059 INFO [-] =========================================================
2015-12-19 18:06:24,059 WARNING [-] Failed to register policy types.
Traceback (most recent call last):
  File "/usr/share/python/st2common/local/lib/python2.7/site-packages/st2common/content/bootstrap.py", line 174, in register_policies
    import st2actions
ImportError: No module named st2actions
2015-12-19 18:06:24,060 INFO [-] Registered 0 policy types.
2015-12-19 18:06:24,060 INFO [-] =========================================================
2015-12-19 18:06:24,060 INFO [-] ############## Registering policies #####################
2015-12-19 18:06:24,060 INFO [-] =========================================================
2015-12-19 18:06:24,060 INFO [-] Registered 0 policies.

stable/unstable paradigm for package repos (rhel direct package link)

I find it quite misleading to have stable/unstable on top of staging and stable (just top ones el6/el7) repos. At least for centos, the current implemented approach works not in sync with standards used by rhel-camp or it might be bintray works bad.

Anyway the issue on the face, if you get package installation directly, it doesn't work due to paths mangling inside the repository.

wget https://bintray.com/stackstorm/el7_staging/rpm -O bintray-stackstorm-el7_staging.repo

I don't know further details, but seems far from being right(

@armab , @lakshmi-kannan

st2web package

st2web needs to be shipped as real package, as @jfryman noted here: StackStorm/community#131

I'm not sure if the packaging codebase/logic should be included as part of st2-packages or st2web repos.

I'll just open it here to have some food for future thinking.

Info

  • There are acceptance Selenium tests for st2web
  • st2web follows almost the same model with versioned branches as st2 repo, eg. v1.1, v1.2 for stable, master for unstable.

For sure:

  • st2web package creation should be triggered when there were new changes in st2web repo
  • We need to upload st2web packages to Bintray (stable for vX.Y.Z branch, unstable for master)

Questions:

  • Is Selenium/Acceptance testing included in StackStorm staging box pipeline (internal testing)?
  • Do we need to upload st2web to Bintray staging repo or we can just upload directly to Bintray production repo? (depends on previous Q)
  • Do we need the same packaging architecture when building st2web package? (spinning Docker containers with different distros) - probably depends on packaging approach/software choosed.
  • ...

[INFO] Collecting Build Stats/Timing

Problem

Mentioned in Slack idea about collecting data on build time/timing and make sure we can track regressions/optimizations:

@jfryman What Iโ€™d like to get a better understanding of wrt CI/Packagesโ€ฆ better understanding of how weโ€™re going to collect data points on timing

Solution 1 - CircleCI Web interface

There is already nice looking graph in CircleCI UI showing time for recent builds:
a11b8oo 1
That's what we already have and it's nice!

Solution 2 - API for custom processing

Advanced option is to use CircleCI API.
Example request: [https://circleci.com/docs/api#recent-builds-project](Recent Builds For a Single Project) outputs recent builds with needed metadata:

  ...
  "start_time" : "2013-02-12T21:33:38Z", // time build started running
  "stop_time" : "2013-02-12T21:34:01Z", // time build finished running
  "build_time_millis" : 23505,
  ...

So we can collect it/process ^^ and display on our side if needed.
Even create StackStorm sensors and rules to trigger blaming ChatOps message if build time is exceeded specified +% threshold :)

FYI @jfryman and @lakshmi-kannan

Can't build in Vagrant

Had no luck building packages in Vagrant under ubuntu/trusty64.

For the moment makes almost no sense digging into it and trying to fix, since it works well under AWS and CI systems.
Let's leave it here just for informational purposes as a known issue, so someone who probably test it later won't try to repeat my experience.

Install dependencies

sudo sh -c "wget -qO- https://get.docker.io/gpg | apt-key add -"
sudo sh -c "echo deb http://get.docker.io/ubuntu docker main > /etc/apt/sources.list.d/docker.list"
sudo apt-get update
sudo apt-get -y install lxc-docker
sudo apt-get -y install python-pip git
pip install docker-compose
git clone https://github.com/dennybaa/st2-packages.git
cd st2-packages

docker-compose up debian

Error:

===> Starting build on bwheezy
     package list: [st2common st2actions st2api st2auth st2client st2debug st2exporter st2reactor st2bundle]
Warning: Permanently added 'bwheezy,172.17.0.4' (ECDSA) to the list of known hosts.
/tmp/tmp.NQAcf99WDZ ~
/tmp/tmp.NQAcf99WDZ/st2common /tmp/tmp.NQAcf99WDZ ~

===> Starting package st2common build
# populate version should be run before any pip/setup.py works
sh ../scripts/populate-version.sh
touch .stamp-populate_version
debchange -v 0.14dev-1 -M "automated build version: 0.14dev"
dpkg-buildpackage: source package st2common
dpkg-buildpackage: source version 0.14dev-1
dpkg-buildpackage: source changed by unknown <[email protected]>
 dpkg-source --before-build st2common
dpkg-buildpackage: host architecture amd64
 debian/rules clean
dh clean --with python-virtualenv
   dh_testdir
   dh_clean
 debian/rules build
dh build --with python-virtualenv
   dh_testdir
   dh_auto_configure
 debian/rules binary
dh binary --with python-virtualenv
   dh_testroot
   dh_prep
   debian/rules override_dh_installdirs
make[1]: Entering directory `/tmp/tmp.NQAcf99WDZ/st2common'
dh_installdirs
/tmp/tmp.NQAcf99WDZ/st2common/debian/st2common.dirs: 1: /tmp/tmp.NQAcf99WDZ/st2common/debian/st2common.dirs: /etc/st2: not found
/tmp/tmp.NQAcf99WDZ/st2common/debian/st2common.dirs: 2: /tmp/tmp.NQAcf99WDZ/st2common/debian/st2common.dirs: /etc/logrotate.d: Permission denied
/tmp/tmp.NQAcf99WDZ/st2common/debian/st2common.dirs: 3: /tmp/tmp.NQAcf99WDZ/st2common/debian/st2common.dirs: /var/log/st2: not found
make[1]: Leaving directory `/tmp/tmp.NQAcf99WDZ/st2common'
dh_installdirs: problem reading debian/st2common.dirs:
make[1]: *** [override_dh_installdirs] Error 127
make: *** [binary] Error 2
dpkg-buildpackage: error: debian/rules binary gave error exit status 2

===> Finished package st2common build sucessfully
/tmp/tmp.NQAcf99WDZ ~
cp: cannot stat `st2common*.deb': No such file or directory

Artifacts Build Time/Speed

The Problem

Let's talk about build time/build speed. The problem is that the time of build is big (no surprises here).

  • ~15min - for debian
  • ~18min - for ubuntu
  • ~27min - for centos7

Considering that for now everything is minimal and real build time is time of the slowest build - we have minimum half of hour to wait before getting any results and we should tie that with GitHub Pull Request status, so the developer can see status ASAP.

This timing is not reliable enough.

The Reason

I thought it's slow because of 3rd party CI, but here are my stats for docker-compose up debian running on AWS c4.large (2 vCPUs, 8 ECUs, 3.5 GiB RAM) which is good CPU-optimized machine:

16 minutes total (4-5 minutes from that took pulling Docker images)
Same timing as we have on CI systems.

Noticed that CPUs were not used very heavily during the build. Saw the same when SSH debugged CircleCI (which has 32 CPUs for one VM) and as you see, almost the same results running in good AWS instance.

So it looks like we need some solution to better use these horse powers and speed up the builds.
For example further parallelize stage when st2-* packages are built (it's biggest and slowest part of entire process).

As I understand, for the moment all packages ST2_PACKAGES="st2common st2actions st2api st2auth st2client st2reactor st2exporter st2debug" are building one-by-one.

Ideas (without research and possible solutions):

  • Caching
    • for docker pull when Docker images are downloaded (it takes from 2 to 5 minutes) (?)
    • for downloading pip packages (?)
    • using built-in CI for Mongo/PostgreSQL/RabbitMQ instead of Docker container (CircleCI and TravisCI have these services preinstalled) (?)
  • Decrease build time for st2-* packages in one distro (linear build -> parallel build):
    • fork parallel build processess in one Docker container and wait for longest to finish (?)
    • BUILDHOSTS instead of BUILDHOST - to build the st2 packages inside several Docker containers in parallel (?)

What can we think about/do else? Or don't worry for now, improve it later?

[deb] st2reactor accidently doesn't depend on st2common

I see there is a dependency in Makefile
But st2reactor for some unknown reason doesn't depend on st2common.

Reproduce (Ubuntu14):

Add repo:

wget -qO - https://bintray.com/user/downloadSubjectPublicKey?username=bintray | apt-key add -
add-apt-repository 'deb https://dl.bintray.com/stackstorm/trusty_staging unstable main'

Install st2reactor

# apt-get install st2reactor

The following NEW packages will be installed:
  st2reactor
0 upgraded, 1 newly installed, 0 to remove and 34 not upgraded.

Only st2reactor is installed (no st2common dependency):

# ls -d /usr/share/python/st*
/usr/share/python/st2reactor

and

apt-cache showpkg st2reactor

shows no depdency.


Probably typo somewhere or something like that in https://github.com/StackStorm/st2-packages/tree/master/packages/st2reactor I don't see.

CI for Mistral

Currently we build and upload same stable mistral version on every push to st2 and st2-packages, which is overkill. It's hardcoded here:

envpass :giturl, 'https://github.com/StackStorm/mistral', from: 'ST2MISTRAL_GITURL'
envpass :gitrev, 'st2-1.3.2', from: 'ST2MISTRAL_GITREV'
envpass :gitdir, make_tmpname('mistral-')
envpass :mistral_version, '1.3.2'
envpass :mistral_release, 1

We should build Mistral only when there was a change/release in https://github.com/stackstorm/mistral repository. Of course, CircleCI should be integrated with mistral repo, same as @enykeev did for st2web.

This will further speed up overall build time for st2-packages and st2 repos, since we won't do unecessarry mistral builds every time.

"Exception: Failed to create virtualenv" during packs.install

Reproduce (Ubuntu14)

wget -qO - https://bintray.com/user/downloadSubjectPublicKey?username=bintray | apt-key add -
add-apt-repository 'deb https://dl.bintray.com/stackstorm/trusty_staging unstable main'

# Install Rabbit and Mongo
apt-get update
apt-get install rabbitmq-server mongodb-server

# Install st2
apt-get install st2api st2actions st2auth st2client st2common st2debug st2exporter st2reactor

# Set `enable = False` under `[auth]` section in file: `/etc/st2/st2/conf`
sudo sed -i '/^\[auth\]$/,/^\[/ s/^enable = True/enable = False/' /etc/st2/st2.conf

# Register content
st2-register-content --register-all --config-dir /etc/st2

# Start everything
service st2api start
service st2auth start
service st2actionrunner start
service st2notifier start
service st2resultstracker start
service st2rulesengine start
service st2sensorcontainer start
service st2exporter start

# Install dependencies for packs.install to work
apt-get install git python-virtualenv

# Install some st2 pack
st2 run packs.install packs=github

Error message

# st2 run packs.install packs=github

....
id: 5675a56dfad0d513e9647150
action.ref: packs.install
status: failed
error: st2.actions.python.SetupVirtualEnvironmentAction: DEBUG    Setting up virtualenv for pack "github"
st2.actions.python.SetupVirtualEnvironmentAction: INFO     Virtualenv path "/opt/stackstorm/virtualenvs/github" doesn't exist
st2.actions.python.SetupVirtualEnvironmentAction: DEBUG    Creating virtualenv for pack "github" in "/opt/stackstorm/virtualenvs/github"
st2.actions.python.SetupVirtualEnvironmentAction: DEBUG    Creating virtualenv in "/opt/stackstorm/virtualenvs/github" using Python binary "/usr/share/python/st2actions/bin/python"
Traceback (most recent call last):
  File "/usr/share/python/st2actions/local/lib/python2.7/site-packages/st2actions/runners/python_action_wrapper.py", line 116, in <module>
    obj.run()
  File "/usr/share/python/st2actions/local/lib/python2.7/site-packages/st2actions/runners/python_action_wrapper.py", line 61, in run
    output = action.run(**self._parameters)
  File "/opt/stackstorm/packs/packs/actions/pack_mgmt/setup_virtualenv.py", line 60, in run
    self._setup_pack_virtualenv(pack_name=pack_name, update=update)
  File "/opt/stackstorm/packs/packs/actions/pack_mgmt/setup_virtualenv.py", line 102, in _setup_pack_virtualenv
    self._create_virtualenv(virtualenv_path=virtualenv_path)
  File "/opt/stackstorm/packs/packs/actions/pack_mgmt/setup_virtualenv.py", line 140, in _create_virtualenv
    (virtualenv_path, stderr))
Exception: Failed to create virtualenv in "/opt/stackstorm/virtualenvs/github": Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/virtualenv.py", line 2339, in <module>
    main()
  File "/usr/lib/python2.7/dist-packages/virtualenv.py", line 825, in main
    symlink=options.symlink)
  File "/usr/lib/python2.7/dist-packages/virtualenv.py", line 985, in create_environment
    site_packages=site_packages, clear=clear, symlink=symlink))
  File "/usr/lib/python2.7/dist-packages/virtualenv.py", line 1181, in install_python
    copy_required_modules(home_dir, symlink)
  File "/usr/lib/python2.7/dist-packages/virtualenv.py", line 1120, in copy_required_modules
    copyfile(filename, dst_filename, symlink)
  File "/usr/lib/python2.7/dist-packages/virtualenv.py", line 467, in copyfile
    os.makedirs(os.path.dirname(dest))
  File "/usr/share/python/st2actions/lib/python2.7/os.py", line 157, in makedirs
    mkdir(name, mode)
OSError: [Errno 17] File exists: '/opt/stackstorm/virtualenvs/github/lib/python2.7/lib-dynload'


traceback: None
failed_on: setup_virtualenv
start_timestamp: 2015-12-19T18:43:57.690729Z
end_timestamp: 2015-12-19T18:44:04.361833Z
+--------------------------+-----------+-------------------+-------------------------+-------------------------------+
| id                       | status    | task              | action                  | start_timestamp               |
+--------------------------+-----------+-------------------+-------------------------+-------------------------------+
| 5675a56dfad0d513ff14be8d | succeeded | download          | packs.download          | Sat, 19 Dec 2015 18:43:57 UTC |
| 5675a572fad0d513ff14be90 | succeeded | virtualenv_prerun | packs.virtualenv_prerun | Sat, 19 Dec 2015 18:44:02 UTC |
| 5675a573fad0d513ff14be93 | failed    | setup_virtualenv  | packs.setup_virtualenv  | Sat, 19 Dec 2015 18:44:03 UTC |
+--------------------------+-----------+-------------------+-------------------------+-------------------------------+

Helpful Info:

Broken symlinks:

/opt/stackstorm/virtualenvs/github/lib/python2.7# ls -l
total 0
lrwxrwxrwx 1 root root 38 Dec 19 18:44 codecs.py -> ../../../../../lib/python2.7/codecs.py
lrwxrwxrwx 1 root root 38 Dec 19 18:44 encodings -> ../../../../../lib/python2.7/encodings
lrwxrwxrwx 1 root root 39 Dec 19 18:44 fnmatch.py -> ../../../../../lib/python2.7/fnmatch.py
lrwxrwxrwx 1 root root 43 Dec 19 18:44 genericpath.py -> ../../../../../lib/python2.7/genericpath.py
lrwxrwxrwx 1 root root 40 Dec 19 18:44 lib-dynload -> ../../../../../lib/python2.7/lib-dynload
lrwxrwxrwx 1 root root 38 Dec 19 18:44 locale.py -> ../../../../../lib/python2.7/locale.py
lrwxrwxrwx 1 root root 38 Dec 19 18:44 ntpath.py -> ../../../../../lib/python2.7/ntpath.py
lrwxrwxrwx 1 root root 34 Dec 19 18:44 os.py -> ../../../../../lib/python2.7/os.py
lrwxrwxrwx 1 root root 41 Dec 19 18:44 posixpath.py -> ../../../../../lib/python2.7/posixpath.py
lrwxrwxrwx 1 root root 36 Dec 19 18:44 stat.py -> ../../../../../lib/python2.7/stat.py
lrwxrwxrwx 1 root root 40 Dec 19 18:44 UserDict.py -> ../../../../../lib/python2.7/UserDict.py

https://github.com/StackStorm/st2/blob/master/contrib/packs/actions/pack_mgmt/setup_virtualenv.py might have answers.

Package Dependencies: git and virtualenv

Core st2 Action st2 run packs.install assumes that git and virtualenv binaries are installed globally in the system.

@dennybaa Sounds like we should include them in Package dependencies.
For which packages then, st2common, st2client?

Use built-in services in CI

Low priority

CircleCI has built-in RabbitMQ, Mongo and PostgreSQL services already up and running.
Instead of downloading respective Docker images, we can use CI services to save some time (2-3 mins).

Since docker-compose supports different configs, depending on environment, this looks like good approach which won't break existing beauty.
http://docs.docker.com/compose/extends/#multiple-compose-files

So for local env and CI env there will be a bit different configs (with and without linked services).

Info: CircleCI

Just for info here, thoughts about using CircleCI for building packages


Same as Travis, it went well in CircleCI with built-in parallel support (3 tasks).
FYI for free (OSS projects) we have 4 isolated VMs running in parallel, - same as Travis.

Example configuration

Pros

  • powerful VMs, 32 CPUs
  • Has deployment section which is triggered when all parallel tasks were finished successfully. That's what we need and what's hard to do in Travis.
  • Has debug ssh mode
  • Parallel nodes can run ssh commands on each other: ssh node0 ssh node1
  • Has artifacts section. You just copy created artifacts to $CIRCLE_ARTIFACTS directory and CircleCI makes them downloadable after the build. See screenshot.
  • Has option to trigger Parameterized Builds via API (see links below).

Cons

  • circle.yml config is not so clear as travis.yml. Configuration was harder with some small issues/dirty hacks. But most probably we want to configure it once and forget about it.

Other Useful links

Some Conclusions

  • I can't say that CircleCI wih 32CPUs is slow, but build time is very near to what we have in Travis:
    • ~15min - for debian
    • ~18min - for ubuntu
    • ~26min - for centos7

Looks like we need some enhancements to further parallelize the builds. I've noticed that CircleCI 32 CPUs were not heavily used during the build. For the moment all packages ST2_PACKAGES="st2common st2actions st2api st2auth st2client st2reactor st2exporter st2debug" are building one-by-one. We should think about improvements here to better use all machine's horse-power.


So far it's better than Travis.
Going to try Drone now.

Make `/opt/stackstorm` owned by `st2`

Is there any particular reason why entire /opt/stackstorm directory is owned by root?
I assume I don't know some specific reason here @lakshmi-kannan @dennybaa.

If there is nothing like that, we can change it belonging to st2 user completely for consistency.
And it would simplify a bit life just from the start.

Currently we run many services from st2 user, logs are owned by st2 user too.
There was also issue before when specific service running from st2 user couldn't access contents of /opt/stackstorm dir.

Freezing on installation stage 'Unpacking st2common ...'

I've played a bit, spinned up the new AWS instance with Ubuntu 14 LTS.

Steps I did:

sudo sh -c "wget -qO- https://get.docker.io/gpg | apt-key add -"
sudo sh -c "echo deb http://get.docker.io/ubuntu docker main > /etc/apt/sources.list.d/docker.list"
sudo apt-get update
sudo apt-get -y install lxc-docker
sudo apt-get -y install python-pip git
pip install docker-compose
git clone https://github.com/dennybaa/st2-packages.git
cd st2-packages

docker-compose run debian

My problem it just stucks here:

Bundle complete! 2 Gemfile dependencies, 16 gems now installed.
Use `bundle show [gemname]` to see where a bundled gem is installed.
Warning: Permanently added 'iwheezy,172.17.0.2' (ECDSA) to the list of known hosts.
DEBUG: scripts/install.sh has been invoked!
/root/build/tmp.IiYwNAjIgR/st2common_0.14dev-1_amd64.deb

===> Staring installation of package: st2common_0.14dev-1_amd64
Selecting previously unselected package st2common.
(Reading database ... 26168 files and directories currently installed.)
Unpacking st2common (from .../st2common_0.14dev-1_amd64.deb) ...

Waited for 20 minutes or so on c4.large instance. It just freezed with no further output. Tried 2 times on new machines.


Some configuration I'm missing maybe (using all defaults)?

Using is wheelhouse with later `--no-index` is dangerous

When we do pre build of wheels in some shared particular directory we can run into race condition.
Such as we do with pecan dependency.
When we populate the shared wheelhouse, both mistral and another st2package create wheels one for version 1.0.3 and another 0.7.0.

Later on when package is built without .cache/pip using --no-index option pip doesn't rely on full dependency scanning (it can't parse version for git+https dependencies), so it chooses the latest...

Do we really need a virtualenv per component?

Patrick has been testing the new packages on an ubuntu box and pretty much hit a roadblock. #53

While we are all talking about it and trying to quickly fix the issue, I want to take a step back and re-assess what's the value of using a virtualenv per component?

Pros:

  • Isolation

Cons:

  • Confusing
  • Actually breaks some some stuff like content management, packs.install etc.
  • Debugging and support are harder

Instead of fixing st2 code which is indeed an option, can we switch to a single virtualenv for all components? Is this possible with dh-virtualenv?

Having a single virtualenv will immensely simplify debugging and support. I am not close to the metal on this. So I really appreciate insights into why we think the current approach was settled on? If it turns out we didn't think this through, let's do it collectively.

Remove specs for debian/ rpm/ except bundle and mistral

cc: @lakshmi-kannan @kirilstrax @armab
I suggest to think about premature optimization.

Honestly, we are not able to ship separate packages in the release. Now we are doing excessive work fixing files in st2* as well st2bundle packages, not all of that is only copy paste work, because it requires manual validation.
My personal feeling that what we are doing is premature optimization, I also have a feeling that after this release we won't look at separate packages.

Pros

  • We get component separation

Cons

  • It's not real life scenario, since even you do some job on fixing package A. It won't work, since you need to propagate code from package A to st2bundle. Unless you've done work is in vain. (also #66)
  • It's not fun validating init files for each service and st2bundle after copy-paste.
  • It's simply duplication of efforts.

PS. component separation should be done in st2bundle package (logical enable/disable).
Please welcome, to discuss! But I'm asking you to be honest in terms of double effort and premature optimization.

Wrong st2client is used in st2bundle

Seems st2bundle somehow uses https://pypi.python.org/pypi/st2client for installation.

st2bundle way:

wget -qO - https://bintray.com/user/downloadSubjectPublicKey?username=bintray | apt-key add -
add-apt-repository 'deb https://dl.bintray.com/stackstorm/trusty_staging unstable main'
apt-get update
apt-get install st2bundle
# st2 --version
st2 ('1.2.0.8',)

Standalone way:

wget https://circle-artifacts.com/gh/StackStorm/st2-packages/227/artifacts/0/home/ubuntu/packages/trusty/st2common_1.3dev-97_amd64.deb
wget https://circle-artifacts.com/gh/StackStorm/st2-packages/227/artifacts/0/home/ubuntu/packages/trusty/st2client_1.3dev-97_amd64.deb

dpkg -i *.deb
# st2 --version
st2 1.3dev

I double checked the source code for both and seems client in st2bundle is really outdated, because it doesn't include recent commit affecting st2client source code: StackStorm/st2@6928e7b

My best guess that the possible cause could be related to: https://github.com/StackStorm/st2-packages/blob/master/packages/st2bundle/in-requirements.txt#L5 ?

Do we really require wheelhouse passthrough?

Looks like ghost bug.

From time to time I get this error in CircleCI wheezy build:
https://circleci.com/gh/StackStorm/st2-packages/36

[package: st2common]      dpkg-shlibdeps: error: couldn't find library libffi.so.6 needed by debian/st2common/usr/share/python/st2common/lib/python2.7/site-packages/_cffi_backend.so (ELF format: 'elf64-x86-64'; RPATH: '')
[package: st2common]      dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/st2common/usr/share/python/st2common/lib/python2.7/site-packages/msgpack/_unpacker.so debian/st2common/usr/share/python/st2common/lib/python2.7/site-packages/msgpack/_packer.so debian/st2common/usr/share/python/st2common/bin/python were not linked against libgcc_s.so.1 (they use none of the library's symbols)
[package: st2common]      dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/st2common/usr/share/python/st2common/lib/python2.7/site-packages/msgpack/_unpacker.so debian/st2common/usr/share/python/st2common/lib/python2.7/site-packages/msgpack/_packer.so were not linked against libstdc++.so.6 (they use none of the library's symbols)
[package: st2common]      dpkg-shlibdeps: error: cannot continue due to the error above
[package: st2common]      Note: libraries are not searched in other binary packages that do not have any shlibs or symbols file.
[package: st2common]      To help dpkg-shlibdeps find private libraries, you might need to set LD_LIBRARY_PATH.
[package: st2common]      dh_shlibdeps: dpkg-shlibdeps -Tdebian/st2common.substvars debian/st2common/usr/share/python/st2common/lib/python2.7/site-packages/Crypto/Hash/_MD2.so debian/st2common/usr/share/python/st2common/lib/python2.7/site-packages/Crypto/Hash/_MD4.so debian/st2common/usr/share/python/st2common/lib/python2.7/site-packages/Crypto/Hash/_SHA256.so debian/st2common/usr/share/python/st2common/lib/python2.7/site-packages/Crypto/Hash/_SHA224.so debian/st2common/usr/share/python/st2common/lib/python2.7/site-packages/Crypto/Hash/_SHA384.so debian/st2common/usr/share/python/st2common/lib/python2.7/site-packages/Crypto/Hash/_SHA512.so debian/st2common/usr/share/python/st2common/lib/python2.7/site-packages/Crypto/Hash/_RIPEMD160.so debian/st2common/usr/share/python/st2common/lib/python2.7/site-packages/Crypto/Cipher/_AES.so debian/st2common/usr/share/python/st2common/lib/python2.7/site-packages/Crypto/Cipher/_ARC2.so debian/st2common/usr/share/python/st2common/lib/python2.7/site-packages/Crypto/Cipher/_Blowfish.so debian/st2common/usr/share/python/st2common/lib/python2.7/site-packages/Crypto/Cipher/_CAST.so debian/st2common/usr/share/python/st2common/lib/python2.7/site-packages/Crypto/Cipher/_DES.so debian/st2common/usr/share/python/st2common/lib/python2.7/site-packages/Crypto/Cipher/_DES3.so debian/st2common/usr/share/python/st2common/lib/python2.7/site-packages/Crypto/Cipher/_ARC4.so debian/st2common/usr/share/python/st2common/lib/python2.7/site-packages/Crypto/Cipher/_XOR.so debian/st2common/usr/share/python/st2common/lib/python2.7/site-packages/Crypto/Util/strxor.so debian/st2common/usr/share/python/st2common/lib/python2.7/site-packages/Crypto/Util/_counter.so debian/st2common/usr/share/python/st2common/lib/python2.7/site-packages/markupsafe/_speedups.so debian/st2common/usr/share/python/st2common/lib/python2.7/site-packages/bson/_cbson.so debian/st2common/usr/share/python/st2common/lib/python2.7/site-packages/pymongo/_cmessage.so debian/st2common/usr/share/python/st2common/lib/python2.7/site-packages/cryptography/hazmat/bindings/_openssl.so debian/st2common/usr/share/python/st2common/lib/python2.7/site-packages/cryptography/hazmat/bindings/_constant_time.so debian/st2common/usr/share/python/st2common/lib/python2.7/site-packages/cryptography/hazmat/bindings/_padding.so debian/st2common/usr/share/python/st2common/lib/python2.7/site-packages/msgpack/_packer.so debian/st2common/usr/share/python/st2common/lib/python2.7/site-packages/msgpack/_unpacker.so debian/st2common/usr/share/python/st2common/lib/python2.7/site-packages/wrapt/_wrappers.so debian/st2common/usr/share/python/st2common/lib/python2.7/site-packages/greenlet.so debian/st2common/usr/share/python/st2common/lib/python2.7/site-packages/_yaml.so debian/st2common/usr/share/python/st2common/lib/python2.7/site-packages/_cffi_backend.so debian/st2common/usr/share/python/st2common/lib/python2.7/site-packages/netifaces.so debian/st2common/usr/share/python/st2common/bin/python returned exit code 2
[package: st2common]      make: *** [binary] Error 2

.circle/docker-compose.sh build ${DISTRO} returned exit code 1

[package: st2common] dpkg-buildpackage: error: debian/rules binary gave error exit status 2 Action failed: .circle/docker-compose.sh build ${DISTRO}

More info

Sometimes just pushing Rebuild button works, sometimes not: several retries needed.

make: *** [binary] Error 2

From time to time still getting errors in Circle, here is an example:
https://circleci.com/gh/StackStorm/st2-packages/148

[package: st2actions]      Collecting st2common (from -r ./requirements.txt (line 18))
[package: st2actions]      Exception:
[package: st2actions]      Traceback (most recent call last):
[package: st2actions]        File "/tmp/st2-20151202-9-13fzc6c/st2actions/debian/st2actions/usr/share/python/st2actions/local/lib/python2.7/site-packages/pip/basecommand.py", line 211, in main
[package: st2actions]          status = self.run(options, args)
[package: st2actions]        File "/tmp/st2-20151202-9-13fzc6c/st2actions/debian/st2actions/usr/share/python/st2actions/local/lib/python2.7/site-packages/pip/commands/install.py", line 305, in run
[package: st2actions]          wb.build(autobuilding=True)
[package: st2actions]        File "/tmp/st2-20151202-9-13fzc6c/st2actions/debian/st2actions/usr/share/python/st2actions/local/lib/python2.7/site-packages/pip/wheel.py", line 705, in build
[package: st2actions]          self.requirement_set.prepare_files(self.finder)
[package: st2actions]        File "/tmp/st2-20151202-9-13fzc6c/st2actions/debian/st2actions/usr/share/python/st2actions/local/lib/python2.7/site-packages/pip/req/req_set.py", line 334, in prepare_files
[package: st2actions]          functools.partial(self._prepare_file, finder))
[package: st2actions]        File "/tmp/st2-20151202-9-13fzc6c/st2actions/debian/st2actions/usr/share/python/st2actions/local/lib/python2.7/site-packages/pip/req/req_set.py", line 321, in _walk_req_to_install
[package: st2actions]          more_reqs = handler(req_to_install)
[package: st2actions]        File "/tmp/st2-20151202-9-13fzc6c/st2actions/debian/st2actions/usr/share/python/st2actions/local/lib/python2.7/site-packages/pip/req/req_set.py", line 491, in _prepare_file
[package: st2actions]          session=self.session)
[package: st2actions]        File "/tmp/st2-20151202-9-13fzc6c/st2actions/debian/st2actions/usr/share/python/st2actions/local/lib/python2.7/site-packages/pip/download.py", line 814, in unpack_url
[package: st2actions]          unpack_file_url(link, location, download_dir)
[package: st2actions]        File "/tmp/st2-20151202-9-13fzc6c/st2actions/debian/st2actions/usr/share/python/st2actions/local/lib/python2.7/site-packages/pip/download.py", line 723, in unpack_file_url
[package: st2actions]          unpack_file(from_path, location, content_type, link)
[package: st2actions]        File "/tmp/st2-20151202-9-13fzc6c/st2actions/debian/st2actions/usr/share/python/st2actions/local/lib/python2.7/site-packages/pip/utils/__init__.py", line 645, in unpack_file
[package: st2actions]          flatten=not filename.endswith('.whl')
[package: st2actions]        File "/tmp/st2-20151202-9-13fzc6c/st2actions/debian/st2actions/usr/share/python/st2actions/local/lib/python2.7/site-packages/pip/utils/__init__.py", line 535, in unzip_file
[package: st2actions]          data = zip.read(name)
[package: st2actions]        File "/usr/lib/python2.7/zipfile.py", line 935, in read
[package: st2actions]          return self.open(name, "r", pwd).read()
[package: st2actions]        File "/usr/lib/python2.7/zipfile.py", line 968, in open
[package: st2actions]          raise BadZipfile("Truncated file header")
[package: st2actions]      BadZipfile: Truncated file header
[package: st2actions]      Traceback (most recent call last):
[package: st2actions]        File "/usr/bin/dh_virtualenv", line 106, in <module>
[package: st2actions]          sys.exit(main() or 0)
[package: st2actions]        File "/usr/bin/dh_virtualenv", line 86, in main
[package: st2actions]          deploy.install_dependencies()
[package: st2actions]        File "/usr/lib/python2.7/dist-packages/dh_virtualenv/deployment.py", line 147, in install_dependencies
[package: st2actions]          subprocess.check_call(self.pip('-r', requirements_path))
[package: st2actions]        File "/usr/lib/python2.7/subprocess.py", line 540, in check_call
[package: st2actions]          raise CalledProcessError(retcode, cmd)
[package: st2actions]      subprocess.CalledProcessError: Command '['/tmp/st2-20151202-9-13fzc6c/st2actions/debian/st2actions/usr/share/python/st2actions/bin/python', '/tmp/st2-20151202-9-13fzc6c/st2actions/debian/st2actions/usr/share/python/st2actions/bin/pip', 'install', '--log=/tmp/tmpF90E6u', '--no-index', '--find-links=/tmp/wheelhouse', '-r', './requirements.txt']' returned non-zero exit status 2
[package: st2actions]      debian/rules:35: recipe for target 'override_dh_virtualenv' failed
[package: st2actions]      make[1]: Leaving directory '/tmp/st2-20151202-9-13fzc6c/st2actions'
[package: st2actions]      debian/rules:14: recipe for target 'binary' failed
[package: st2actions]      make[1]: *** [override_dh_virtualenv] Error 1
[package: st2actions]      make: *** [binary] Error 2

Retrying build without cache fixes the problem. However I'm not sure, it could be not related to cache, just re-build probably works.

Maybe you have better idea reading this error message and understanding the cause.

Info: DroneCI v0.4

So I've installed and played a lot with Drone 0.4 on AWS. This version (under heavy development, but will be released soon) adds build matrix support, comparing to stable 0.3.
But I couldn't make Drone working as expected with our config. It's possible to fix it somehow via running docker-compose from docker inside docker, but some features are still unfinished.

Pros

  • Self-hosted. That's awesome thing with wow-effect that you can host your own TravisCI-like system with nice UI and all the bells and whistles for free.
  • Really loved their slick/minimal UI, and check that API page design, - just wow!
  • Full control of everything: machine power/settings, even contribute to codebase and write your own plugins (in Go).
  • Docker layers are cached on host's (main) machine, as usual when running Docker. Once docker image is downloaded - no need to re-download it again in future builds how it is in isolated Travis or Circle. This saves 2-4 minutes of build time in our case.

Cons

  • No parallel builds. That was very surprising, but yes - builds in matrix are executed one-by-one. Confirmed by core developers, this feature is not implemented yet. Coming in v0.4.1
  • No option to run deploy when all builds in matrix succeeded. Eg. every build runs its independent deploy callback, no matter if others failed. However something like that is planned in future.
  • Linked services logic was slightly changed in v0.4 comparing to v0.3, making impossible to run our existing configuration/script without refactoring. Instead of making linked services available by host, they are now all listen on localhost. See Core developer answer. Because of this change we can't really sync docker-compose config with new drone.yml config, how it was in 0.3.
  • No native docker-compose configuration support. Since ^^ failed, I've tried to run docker-compose by sharing and re-using docker.sock of host machine. I could run docker-compose, but there is no easy way to share the contents of $DRONE_DIR which is working directory and redirect other variables from Drone build container. So the working solution will be dirty hack on dirty hack.
  • No option via API to trigger the new build with specific parameters. Better API functionality is upcoming thing, as core developers said.

Try 1:

Trying new Drone v0.4 linked images format:

  • .drone.yml configuration used

    See that services like mongodb are accessible via 127.0.0.1:27014, not by host. Most probably it's made to be "user friendly" and easier in basic configurations, but our config is not that easy. I remember from my previous startup such things when we assumed "what is better" for user ๐ŸŒต

Try 2:

Running docker-compose from docker:

Runs docker-compose from docker inside the docker.
Needs changing the script logic and sharing the working directory of current build.

References:


So Drone 0.4 looks like definitely good thing in some future.
I really liked community support in their Gitter chat and overall it looks like it's developed by good guys (same feeling as with StackStorm), but overall system still missing needed features and it's still under heavy development.

Feels like if we start using it - we'll need to learn and hack in Golang to contribute fixes/extend our CI logic with plugins, what might be good thing from some point :) Same as we asking in #community to contribute st2.

I have some crazy ideas about Drone 0.3, will try it soon ๐Ÿ”จ

centos6 rpm st2auth postun requires a fix

Running Transaction
  Erasing    : st2auth-1.3dev-1.x86_64                                              1/9 
Non-fatal POSTUN scriptlet failure in rpm package st2auth
/var/tmp/rpm-tmp.otnoFA: line 7: fg: no job control
warning: %postun(st2auth-1.3dev-1.x86_64) scriptlet failed, exit status 1

WSGI for st2api and st2auth

Current PR in progress: #100

TODO:

  • st2auth/st2api socket decision - use http
    • unix socket creation permission problems
    • unix socket ownership and how to deal with external nginx/apache/lighttpd
  • Make it minimally working (automated tests)
    • deb
    • rpm
  • Replace uwsgi with gunicorn for st2auth. So both st2auth and st2api will use the same consistent solution.
  • Add basic port tests for st2api and st2auth: #103
  • [bug] Identify and fix st2api not listening issue: #106
  • Manual Tests

Old/obsolete commits with discussions:

Info: TravisCI

Just for info here, thoughts about using TravisCI for building packages


Build went well in TravisCI with 3 tasks running in parallel:

Example configuration

Things I don't like

  • It's pretty slow. Fastest is debian (15 min). But the overall build time is time of slowest task which is centos7 (28 min 10 sec). Not reliable enough for CI tied with GitHub.
  • TravisCI has no callback when all tasks completed successfully (we need to upload artifacts when everything went well), see travis-ci/travis-ci#929. However there is 3rd party workaround travis_after_all https://github.com/dmakhno/travis_after_all , so it's doable somehow.
  • Less likely we can tie it into st2 repo, because there are already existing unit/integration tests running in TravisCI for st2
    • Configuration will be mess if we merge package builds and unit/lint/integration tests into one thing in TravisCI
    • Not enough parallel slots (4 free for OSS projects: we already use 4 in st2 and 3 parallel slots for packages here)
    • In GitHub Pull Request status it's better to separate logically different builds by using different CI, so every CI can show its status ASAP.

Going to try CirlecCI now and dig into Drone docs later.

Share logs for each Distro via CircleCI Artifacts

Share /var/log/st2 and service logs via CircleCI artifacts for each distro, so we could read these files later if something wrong appears.

This will help to investigate problems better on fly when some ghost bug appears and identify root cause of issue, example: #100 (comment)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.