Inside the container when we invoke `nohup [...] &` it immediately
returns and `wait-for-enable` starts checking `ps aux` for extension
binary. However since travis environment is not fast, `wait-for-enable`
exited immediately once before the process started.
Adding a 1s delay while polling for exit of extension process should
solve this problem.
- change sudo:true so that we can get a Docker engine
- this will slow down the time to get a test box (a few mins)
but it should be fine
- add bats in 'install'
- print docker info prior to testing
- execute bats
Since #39 is adding a shim that daemonizes 'enable' command and
exits and shim is the entrypoint of the container command, Docker
will kill the container when that entrypoint exits (will not wait
background process to finish). This adds a `wait-for-enable` command
that we use in integration tests. It runs inside the test container
and loops indefinitely until the background process exits.
When AZURE_STORAGE_ACCOUNT and AZURE_STORAGE_ACCESS_KEY passed,
we now have a scenario that runs by uploading two 512k files to
Azure Blob Storage and configures extension to download it.
We verify by checking test container fs diff to see files are
downloaded and we verify checksum on one of the files.
Plumbing logger reference into the download package so that
users can get more visibility into the download failures
during the retries by looking at the logs.
The integation tests use `bats` to run the scenarios as bash scripts.
To test the extension handler functionality, we simply:
- build a Docker image using test.Dockerfile
- copy some files from ` make it look like a `/var/lib/waagent` directory
- copy extension binary into the container
- remove the `test` container if it exists
- create a Docker container (name: `test`) from image
- specify which handler subcommand will be invoked (e.g. `fake-waagent
install`)
- push .settings file and certificate/private key (.crt, .prv)
- do other things on the container that we need to craft the environment
- start the container
- collect the output from the command execution
- validate using the following:
- check status code
- validate output of the command
- `docker diff test` to validate file changes in the container
- copy files out of container and validate their contents
Signed-off-by: Ahmet Alp Balkan <ahmetalpbalkan@gmail.com>
This change actually gives us a functioning extension handler.
- We store data at /var/lib/azure/custom-script (created upon 'install')
- This is different than what old extension does.
- This data directory removed upon 'uninstall'.
- Opereations 'update' and 'disable' is no-op (same as before)
- Processed sequence number file (formerly known as 'mrseq') now resides
at this data directory. This way agent does not need to move the
'mrseq' file around.
- Operation 'enable' is where the magic happens and it is clear to follow.
- parses handler settings
- creates download/output directory
- download the files
- runs the command
- There is no 'daemon' subcommand yet as I am planning to invoke 'enable'
via a shim that does double-fork and log forwarding to a custom log path
(e.g. /var/log/azure/custom-script.log)
- Moved the check for 'commandToExecute' not empty from json-schema validation
to logical validation.
Signed-off-by: Ahmet Alp Balkan <ahmetalpbalkan@gmail.com>
Built a containerized environment that looks like an actual VM
and wrote a fake agent which you can invoke the extension binary
through.
Refer to the integration-test/env/README.md.
This helps us test:
- agent binary can handle the directory structure presented by waagent
- agent binary can handle the HandlerEnvironment, log dirs etc
- agent binary decrypts/parses the settings correctly
- agent binary can write status to the right place
By containerizing there will be no residue left on the dev machine
while testing the changes.
Signed-off-by: Ahmet Alp Balkan <ahmetalpbalkan@gmail.com>
Added a Makefile with binary build step and used Go linker
options to parse the version number, git commit, build date
and the state of build tree as version string to the built
binary.
Signed-off-by: Ahmet Alp Balkan <ahmetalpbalkan@gmail.com>
- github.com/go-kit/kit/log
- github.com/go-logfmt/logfmt
- github.com/kr/logfmt
- github.com/go-stack/stack
Signed-off-by: Ahmet Alp Balkan <ahmetalpbalkan@gmail.com>
This package was designed to be used to make sure we do not
execute same or lower sequence numbers more than once. Changing
the method accordingly to be more useful in that regard.
Signed-off-by: Ahmet Alp Balkan <ahmetalpbalkan@gmail.com>
Ahmet Alp Balkan