floydhub/floyd-cli

Better module release strategy for backward compatiblity

rmdort opened this issue · 6 comments

rmdort commented

It seems that every new release of the module or any update to floyd breaks existing workflows.

I had contacted your team before, so that if any breaking changes are released, you will notify the users about it. But i guess nothing is being done about that.

Floyd is really becoming a integration pain for us. I hope someone is listening.

houqp commented

Hi, sorry I didn't expect this to break your workflow. Could you let us know which api you are using? It's possible that your workflow got interrupted because we removed some unused fields from the api response.

If you let us know what's needed from your side, I can write a simple client that only gets what's required from your side. We did make sure to not break the core functionalities.

EDIT: feel free to send us emails too if you prefer to discuss use-case privately.

rmdort commented

Yes it did.

Previously i could download all my output files using the resource URI (which i get from job status API) . This was a public URL. Now you are using a s3 url as the URI and this s3 bucket is private.

So I cant download my output anymore unless i use floyd data clone . You are forcing users to use CLI for everything. And even when using the CLI to download output, i cant even mention where i want it downloaded.

Please don't deploy features in a rush and break it for paying clients. The least you could do is mention breaking changes in the releases.

houqp commented

I totally understand your frustration. This is an oversight from us. It's caused by a major revamp of our storage infra that would give IO intensive jobs 1-10X speed up. We took extra care on rolling out this change. Unfortunately, our automated tests missed the output command and no one reported this issue to us during the dark launch.

We have no intention to force users to use the CLI. We want users to pick the best tool they prefer to get the job done, be it the WEB UI, CLI or API. Now that I know downloading output is an part of your automated workflow, I will make sure to add more automated tests for that code path to guard against bugs like this in the future.

In the mean time, here is how you can programmatically download the output to a given directory in Python:

import sys
import os
import floyd
from floyd.client.data import DataClient

output_name = 'username/projects/name/1/output'
download_dir = '/var/tmp/download'

data_source = DataClient().get(output_name)
if not data_source:
    print("ERROR: Cannot download output from running job.")
    sys.exit()

os.chdir(download_dir)
DataClient().download_tar(
    url="{}/api/v1/resources/{}?content=true&download=true".format(floyd.floyd_host, data_source.resource_id),
    delete_after_untar=True)

Lastly, I would like to mention that this is not an intentional breaking change. We do put up notice ahead of time on our website to notify breaking changes. I understand this is not the best way to notify critical changes. So going forward, we will also put in a system to send those notifications through emails.

Let me know if there is anything else we can do to help make it easier for you to automate the integration and make it more robust going forward.

rmdort commented

thanks for your understanding. I totally support continuously updating your services. But do help mention breaking changes either in github or via email notifications.

Can you point me to the page where breaking changes are published?

Another pain with floyd automation is the token, which expires every week. (i dont know why) . There is no API to renew it automatically. We have to manually copy the new token from floydhub console and update all our services.

  • 👍1
houqp commented

Thanks for your understanding too as we improve the experience for your integration!

Currently our breaking change is published in the left bottom notification widget on our web UI, which sadly requires you to login into the WEB to see it. This certainly is not good enough for automations. We will make sure to email you ahead of time on breaking changes in the future.

With regards to auth token. Yes, we are aware of this. And I think you also filed a issue for it :) We are actively working with our auth provider to come up with a solution. There are two approaches we are evaluating right now. One is to have users send credentials directly to our servers, the other one is to support revokable API keys for each account that has a configurable expiration date. I will keep you posted on the progress.

narenst commented

The cli now supports credentials based authentication. See: https://github.com/floydhub/floyd-cli/releases/tag/v0.10.18