meltwater / lighter Goto Github PK

Hi,

I encrypted an api key using secretary as follows:

echo -n <some_api_key> | ../../secretary encrypt

Then I placed this encrypted key in a yaml file and ran lighter verify:

./lighter verify /path/tomy/config/config.yml

I am getting the following error:

RuntimeError: The env var 'bugsnag.apiKey' is not a valid shell script identifier and not supported by Secretary. Only alphanumeric characters and underscores are supported, starting with an alphabetic or underscore character.

Not sure if this is a secretary issue or lighter, but I thought I would file an issue here to get some help. Thank you for your time.

Could this project be reorganized into a real python package? It's many times easier for users to work with.

Make a new repo from /src
Make a setup.py file in the root directory:

from setuptools import setup

setup(
    name='lighter',
    version='1.0.0',
    packages=['lighter'],
    scripts=[
        'scripts/lighter',
    ],
    install_requires=[
        'autopep8',
        'joblib',
        'mock',
        'flake8',
        'pyinstaller',
        'pynacl',
        'pyyaml',
        'requests',
        'packaging',
        'cffi',
    ],
)

Make a scripts/lighter file:

#!/usr/local/bin/python

import lighter.main as lighter

lighter.main()

Alter the lighter/main file:

Replace:

if __name__ == '__main__':

With:

def main():

At the end of the file, add:

if __name__ == '__main__':
    main()

Once submitted to pypi, users can easily install it on their machine with pip alone.

Here is an example of what the entire repo would look like:
lighter.zip

The instance count of a Marathon service can be modified by some other actor (e.g. manually or by an auto-scaler). Currently Lighter would overwrite the custom instance count on the next deployment.

Enable Lighter to preserve the custom instance count if it's externally changed. Lighter should still modify the instance count if it's not externally changed.

Example algoritm

• Add a com.meltwater.lighter.instances = N label on the service when Lighter deploys it. The label com.meltwater.lighter.instances should always be set by Lighter to what the service.config.instances is configured to in the yaml files.
• At next Lighter run, if com.meltwater.lighter.instances differs from prevVersion.instances then autoscaling has happened. In this case set service.config.instances = prevVersion.instances to preserve the autoscaled instance count.

Hi all,

sorry if this title sounds a little offensive, but trying to get it to run feels slightly backstabbing. However, I am looking for a good deployment tool (ideally CLI) that we can use on top of our Marathon/Mesos cluster(s) and from the first look, lighter seems like a very good idea.

However, I noticed quite a few pains.

• the Dockerfile is not working at all and poorly respecting best practices
• the shell scripts (such as /commone.sh and /lighter and /test use set -x, something you should only do while debugging your code - not in production.

I'd be willing to provide some PRs, however, I have proven zero knowledge in Python, also, done 3-liner PRs feels like we're all better off if you just $EDITOR $thefile && git commit -a && git commit yourself. Please correct me, if I can still be at help.

Last but not least,
will you continue using lighter in our own (production??) environment, or what will the expected TTL be?

Many thanks, and looking forward for your reply,
Christian.

If I set a property to say an integer and at same time use an encrypted property lighter's verify command fails with a hard-to-understand error message.

Ex:

env:
    secret_password: '...'
    numeric.property: 1

Just like what Lighter can already do for DataDog

http://obfuscurity.com/2014/01/Graphite-Tip-A-Better-Way-to-Store-Events

Purpose is to fail continuous deployment jobs when a deployment/rollout fails to complete.

• Enable Lighter to wait for deployments to complete (in parallel, with timeout)
• Show progress of deployments
• Exit code based on deployment success/timeout to fail CD jobs on deployment failures